O resultado foi um sucesso! Ao que tudo indica, o cliente ficou bem satisfeito. Leia o relato:

Fonte: https://twitter.com/#!/JocaTorres/status/106522197576777728

Até a próxima missão!

A essência do design aplicado na web

O ponto mais importante de todos talvez seja: não tente imaginar a mídia web como se fosse mídia impressa. São realidades completamente diferentes! Na mídia impressa usamos CMYK, na web RGB. A mídia impressa usa centímetros, já a web usa pixels. Na mídia impressa a tipografia é estática (como uma foto), na web a tipografia muda de acordo com o ambiente (como se tivesse vida).

Nós precisamos entender que a essência do design é sempre mesma¹, porém a aplicabilidade deve ser sempre de acordo com o tipo de trabalho. Nenhum website é entregue encadernado.

¹ – Uma sucinta explicação do que é design: imaginar, elaborar e confeccionar algum artefato, utilizando a arte criativa para conceber o resultado.

Webdesign não é print screen

Imagine a seguinte cena: o programador abre sua IDE de desenvolvimento, programa todas as rotinas necessárias para uma determinada funcionalidade ter vida, salva um arquivo .txt e apresenta para a sua equipe. Não tenha dúvidas de que a maioria vai pensar: “Legal, código bonito, mas não seria melhor ver como ele funciona?”. A sensação que eu tenho sobre o que nós pensamos sobre webdesign é a mesma. O indivíduo abre o Photoshop, faz uma deslumbrante tela e apresenta o resultado em imagem estática. Pensem: uma página web é como um organismo vivo, que pode se manifestar de formas diferentes de acordo com o ambiente. Ou seja, o que determina a boa disposição de um layout são os textos, imagens, multimídia ou qualquer outro compontente que o componha.

Completando sabiamente o assunto, Zeldman outro dia disse:

Content precedes design. Design in the absence of content is not design, it’s decoration.

Seja qual for o projeto, o mais importante de tudo sempre será o conteúdo.

Não quero dizer que todo webdesigner deve ser um guru de HTML, CSS e — quem sabe — JavaScript, mas é imprescindível que se tenha a noção de quais recursos usar para tornar um print screen realidade. Eu costumo julgar a qualidade de uma marcação HTML/CSS da mesma forma que julgo layouts. Penso ser tudo parte de um mesmo universo. O webdesigner precisa entender que aquele título feito em 20pt no Photoshop precisa ser um <h1> ou <h2> (dependedo do caso), para atribuir SEO ao site, por exemplo.

Webdesign e as Metodologias Ágeis²

Tenho percebido que há uma carência muito grande de webdesigners que saibam trabalhar com Metodologias Ágeis. E isso é uma pena, porque o sentido da metodologia ágil — ao pé da letra — é tornar a equipe unida e produtiva em toda as fases do projeto. Estariam os webdesigners sendo individualistas?

² – Uma metodologia ágil é aquela que une diversos princípios para melhorar a comunicação entre todos os envolvidos num projeto (inclusive o cliente) e também ajuda na concepção do que realmente precisa ser feito, sempre respondendo às mudanças que o produto sofre, não se apegando à especificações imaginárias.

Falando especificamente de Metodologias Ágeis, alguns Scrum Masters optam por adiantar os sprints de design, fazendo, assim, os chamados mini-waterfalls, outros, como eu, preferem integrar as tarefas de design junto das demais. Cada um tem a sua justificativa (o link do mini-waterfall explica um pouco disso) e a minha está ligada ao que falei acima: conteúdo precede o design. Não vai ser útil ter só a tela do photoshop, porque aquela paginação pode precisar de 20 itens por página e não 10, aquela galeria pode precisar de um controle para remover a foto que o webdesigner não imaginou no seu desenho, o nome do usuário fulano pode ser grande o suficiente para quebrar a caixa de profile e assim por diante.

Fazendo o webdesigner pensar fora da caixa

• O webdesigner precisa descobrir que desenhar em marcação é possível! Isso vai facilitar, inclusive, o trabalho dos programadores;
• Precisa estar próximo da sua equipe e interagir com ela;
• Precisa entender que o seu trabalho não é meramente decorativo. É evolutivo. Do wireframe à marcação. Da marcação à UI/UX. Da UI/UX à identidade visual.
• Conheço diversos programadores que gostam de entender o mundo do webdesign para tornar seu trabalho melhor. É essencial que o webdesigner tenha a mesma motivação. Entender de social coding pode ser um excelente começo.

Este post não tem nenhuma relação comercial com a Hostnet. Quero apenas mostrar como foi bastante simples fazer do GitHub o repositório padrão dos meus deployments.

¹ – Para quem não sabe, o GitHub é um excelente hosting para compartilhamento de arquivos e monitoramento de projetos web. É baseado em Git, que talvez seja o melhor sistema de controle de versão da atualidade.

Foi tão simples que penso ser necessário apenas três passos.

1. Criando um projeto no GitHub

Crie um novo projeto através do seu menu de repositórios. Tendo o link de clone do projeto em mãos, será necessário seguir os passos que o GitHub descreve na primeira tela do seu projeto. Basicamente, é preciso instalar o Git na sua máquina (caso ele não esteja instalado) e configurar o seu ambiente².

² – O meu ambiente já tinha uma SSH Key configurada. Portanto, não me aterei a este detalhe. Veja o tutorial do próprio GitHub que explica como gerar a sua.

2. Configurando o ambiente

Crie a pasta do seu projeto (ou vá até o seu projeto existente) e digite os seguintes comandos:

1
2
3
4
5
6

$ git init
$ touch README
$ git add README
$ git commit -m 'first commit'
$ git remote add origin git@github.com:seu_usuario/seu_projeto.git
$ git push origin master

Seu branch master agora está pronto para receber os arquivos do projeto. No meu caso, o projeto já estava criado. Então, bastou que eu adicionasse todos os demais arquivos e fizesse um novo push.

3. Alterando a receita de deploy da Hostnet

Na página de tutoriais da Hostnet é possível encontrar um tutorial de como criar sua receita de deploy para Capistrano.

Para indicar que o GitHub era o novo repositório padrão, bastou incluir:

1
2
3
4
5
6
7
8
9

# ------------------------------------------------------------------------------
# Git config.
# ------------------------------------------------------------------------------
 
set :repository, "git@github.com:RamonPage/meu_novo_projeto.git"
set :scm, :git
set :scm_passphrase, ""
set :git_shallow_clone, 1
set :branch, "master"

Ou seja, basicamente indiquei o :scm como :git e adicionei alguns parâmetros que podem ser encontrados aqui. O :scm_passphrase não era necessário, então deixei em branco.

Após, comentei duas das linhas logo abaixo. No arquivo pede explicitamente para não alterar, mas era necessário :)

1
2
3
4
5
6

# ------------------------------------------------------------------------------
# Não alterar daqui pra baixo!
# ------------------------------------------------------------------------------
#set :scm, :none
set :deploy_via, :copy
#set :repository, File.expand_path( File.join(File.dirname(__FILE__), "/..") )

Linhas com o :scm e o :repository comentadas, já que o GitHub foi indicado como repositório padrão nas linhas acima.

Finalizando

1
2

$ cap deploy:setup
$ cap deploy

Se tudo der certo, seu projeto hospedado na Hostnet agora pode contar com o poder do Git :)

ATENÇÃO: Esta configuração ficou perfeita para o ambiente do meu projeto, porém não há garantias de que seja a adequada para o seu também. Faça as modificações por sua conta e risco. Não me responsabilizarei por elas. Boa sorte!

A sugestão é do Felipe Mesquita, que na época disse:

Acho que seria interessante que após fazermos uma consulta para ver como ficou uma palavra, tivessemos um link para a consulta. Assim, poderiamos passar esse link para qualquer pessoa.

Pois então, Felipe. Agora é possível. :)

Agora que a coisa ficou séria, eu mergulhei de vez neste projeto. Algumas novidades já estão no ar. Saiba quais.

Ordem do resultado

Descobri depois de alguns dias que o resultado das correções ficaria melhor aparencendo antes do formulário. Assim, quem tem uma resolução vertical (altura de tela) não muito ampla pode ver o resultado com mais facilidade

Tooltips para dicas!

Tooltips são os chamados “balões” que são muito usados em certos sites. Eles são apresentados quando passamos o mouse sobre determinada área. E no Ortografa! não é diferente. Passe o mouse sobre a correção marcada para ver uma dica. Adianto que, por enquanto, nem todas as correções possuem dica. Estou atualizando periodicamente.

Ah! O pessoal do iPhone pode ver a dica dando um “tapa” com o dedo na correção.

Agradecimentos

Quero agradecer a todos os e-mails que tenho recebido. Deixo aqui meu muito obrigado a todos que estão me ajudando neste projeto. Sugerindo, criticando e elogiando. A participação de vocês é muito importante.

Muitíssimo obrigado a todos! :D

O Ortografa! nasceu de uma súbita ideia quando o Acordo Ortográfico da Língua Portuguesa começou a ser adotado no início de 2009. A funcionalidade é simples: digite sua frase no campo acima que o sistema procurará trocar as palavras para a ortografia correta. Caso ele não consiga — certamente por haver alguma ressalva — ele mostrará uma dica para você se guiar nos seus textos.

O projeto

Ortografa! é um projeto simples que idealizei por volta do dia 02/01 deste ano. Queria desenvolver algo diferente que qualquer pessoa — principalmente as crianças — pudesse utilizar e entender o resultado, não sendo um serviço apenas para pessoas mais bem instruídas tecnologicamente.

O projeto é baseado em Expressões Regulares revestidas de jQuery. O serviço é leve e possui apenas 960kb de tamanho (arquivos, ícones e imagens).

Ah! Utilize o Ortografa! no seu iPhone também! :)

Considerações finais

Gostaria muito de receber as impressões sobre o projeto, principalmente em como melhorá-lo. Você professor, passe o Ortografa! aos seus alunos. Discuta com eles, difunda a colocação correta do nosso português.

No Brasil nós temos disto: só nos preocupamos com uma coisa quando ela começa a afetar a nós mesmos. Então, já que antes a grande massa não se importava tanto com a boa colocação do português a nova ortografia acabou chegando como um incentivo para a educação das pessoas (apesar de eu não concordar com ela).

A grande problemática do projeto foi o tempo, pois dispunha de um prazo pequeno para implementação. Mesmo assim, o pessoal da Improve It foi bem solícito e tivemos uma boa sinergia no andamento do trabalho.

Por fim, nasceu o template “mosaico”, com uma paleta de cores mesclada entre o azul e o marrom.

Em breve, mais novidades minhas no Be on the Net. :)

1. Compatibilidade dos browsers

A expectativa é de que em 2009 (data programada para um novo rascunho) o HTML5 já esteja suportado na maioria dos browsers modernos, mas não por completo.

Assim como a guerra dos browsers propõe, cada browser deve se basear primeiramente naquilo que lhe convém. Dentro deste tema, será interessante ver a abordagem das tags <audio> e <video> que certamente implicarão em interesses pessoais de Microsoft (Media Player) e Apple (QuickTime).

2. Implementação incompleta

Veja uma pequena lista de implementações catalogada pelo pessoal do whatwg, cujo trabalho é voltado exatamente no HTML5.

Veja outra lista no wikipedia. O Opera Browser (Presto Engine), como já é de se esperar, tem o melhor suporte até então.

3. Cultura

Passamos um bom tempo até chegarmos numa web satisfatória (mesmo que numa percentagem pequena ainda). Poucos anos atrás, não existia a preocupação nos desenvolvedores em manter a marcação de seus sites organizada, que dirá pensar em standards: era perda de tempo demais!

Agora, nos deparamos com uma nova realidade, já que até quem trabalha com XHTML 1.x poderá se converter para o HTML5. Mas, será que os desenvolvedores querem mesmo isso? Esse ponto é importantíssimo para aqueles que correlacionam padrões web apenas com XHTML. Ledo engano.

John Resig, aquele do Jquery, escreveu no início do ano sobre uma forma prática de implementar sempre o mais recente DOCTYPE nas marcações. Essa técnica será válida para o HTML5. Assim, os desenvolvedores poderiam continuar com seu HTML4 e ir adicionando funcionalidades ao longo do tempo — de acordo com a compatibilidade dos browsers — dentro da marcação HTML5. Como o DOCTYPE não define a versão da marcação, ele sempre procurará corresponder à mais recente encontrada.

O código é simples:

<!DOCTYPE html>

Essa seria uma forma interessante de comerçarmos a nos acostumar com o HTML5.

Conclusão

Apesar de existir um longo caminho até o HTML5 substituir completamente o HTML4, estamos próximos de conseguirmos utilizá-lo aos poucos, já com certa compatibilidade de recursos nos browsers. De qualquer forma, penso que a “cultura” que trato neste artigo está diretamente ligada à previsão de 2022 tratada no artigo anterior, visto que certamente haverá um bom tempo até que alguma parte dos desenvolvedores/webdesigners se conscientizem da nova realidade. Vale lembrar que tínhamos bom suporte à HTML standard há muitos anos (mais de uma década) e só agora, desde poucos anos atrás, nos tocamos disso. :P

A velocidade crescente dos serviços web 2.0 (sim, hoje não temos mais portais, temos serviços) tratou de aumentar a curiosidade dos profissionais que antes não atentavam para a nova web. E em meio a essa avassaladora mudança, algumas implementações da web semântica podem confundir.

Os tempos mudando

Neste mês de setembro o Google lançou seu navegador, o Chrome. Com ele o Google acabou conseguindo — com sua conhecida persuasão — fazer com que pessoas com pouco conhecimento de internet entendessem que a internet não está diretamente ligada ao IE.

E onde o HTML5 entra nisso tudo?

Com a vinda do Chrome e o suporte a CSS 3 cresendo nos browsers modernos, um outro trabalho entrou em check: e o HTML5, como anda?

Semana passada, Jeff Croft tocou num assunto interessante: segundo a previsão, o HTML5 só estará definitivamente recomendado para uso em 2022!

Em entrevista ao blog TechRepublic, Ian Hickson, editor do HTML5, estimou a seguinte linha de tempo:

• Primeiro rascunho da W3C em outubro de 2007;
• Próximo rascunho programado para outubro de 2009;
• Chamada para contribuições em testes em 2011;
• Recomendação candidata em 2012;
• Primeiro rascunho dos testes em 2012.
• Segundo rascunho dos testes em 2015.
• Versão final dos testes em 2019.
• Mais uma chamada para rascunho em 2020.
• Recomendação proposta em 2022.

Quanto tempo, não? A resposta para a demora é de que o HTML4 foi pouco documentado e o HTML5 pretende chegar com muitos novos recursos, assim como o CSS3 também propõe. Para os que não costumam trabalhar com XHTML, o jeito é continuar com o HTML4 por mais um tempo.

Como ter um site standard trabalhando com HTML4

Simples! Como disse no início, tudo depende da definição do DOCTYPE. Não importa o DOCTYPE, desde que você não deixe de usá-lo.

Roger Johansson, do 456 Berea Street já trata do assunto faz tempo. Em 2006 ele explicou porque decidiu pelo uso do HTML em suas marcações. Até hoje ele mantém seu site em HTML4, e válido!

Então, enquanto o HTML5 não chega, tratemos de nos preparar para ele, começando pelo uso de um DOCTYPE adequado e seguindo todas as premissas para um projeto standard de verdade. :)

Atualização 2008-09-16: um DOCTYPE recomendável em HTML4 seria como o a seguir:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Tirando algumas restrições, como o uso de javascript em alguns casos e <span> em outros, fiz uma mistura entre estas soluções e adicionei ao recurso já criado Grid layout para formulários.

Veja um exemplo.

Peneirando…

As soluções [2] e [3] foram as que mais me agradaram, porém tinham o inconveniente do uso de <span> na marcação. Para não perder a viagem, gostei muito do estilo dos WII Buttons e usei a imagem deles como exemplo para a minha solução.

Criando os botões

A solução foi simples, pois o grid layout já tinha o <label> como container dos botões de submissão. Resolvi, então, explorar este ponto para gerar os botões arredondados.

Basicamente, criei apenas uma classe adicional para os labels que possuem botões. Chamei-a de lblbutton. A criação ficou da seguinte forma:

Antes…

1. <label class="small"><input type="submit" class="button" value="Enviar" /></label>

… Depois

1. <label class="small lblbutton"><input type="submit" class="button" value="Enviar" /></label>

E no estilo…

1. .lblbutton {
2. margin: 0;
3. padding: 0 0 0 8px;
4. background: #fff url(bg-button.gif) no-repeat 0 0;
5. }
6.  
7. .lblbutton .button {
8. border: 0;
9. padding: 0 8px 0 0;
10. background: #fff url(bg-button.gif) no-repeat top right;
11. height: 24px;
12. }

Então, é isso! Enjoy! :)

Baixe os arquivos via Google Code