Olá a todos! Tomei a iniciativa de criar uma “coluna” no blog para contar as histórias dos cases da Milk-it. Vou começar a coluna contando a história do nosso próprio site.

Muitos aqui não sabem, mas a Milk-it ficou um ano sem site. Não tínhamos condições de parar algum projeto para nos dedicar somente ao nosso site, e ainda não temos, mas é com isso que entra a parte interessante. Eu, Lucas e Carlos sabíamos que uma empresa de tecnologia sem site é equivalente a um cavaleiro sem cavalo - me perdoe a analogia hehe. Pensando assim, resolvemos aproveitar a semana em que um projeto estava em homologação e decidimos botar a “mão na massa”. Uma semana é muito pouco? Sim, também achamos, mas conseguimos!

1ª Etapa - Elaboração das telas

Por sorte o Lucas havia elaborado uma idéia de layout para o site em suas horas vagas. Isto facilitou muito o nosso trabalho por conta do tempo que tínhamos disponível, porque não precisávamos passar pelo famoso ócio criativo.

Aqui na Milk-it temos um quadro branco que serve para rabiscarmos idéias e tarefas, então fizemos uma reunião para definir os elementos que vão ter nas telas e os fluxos delas. A imagem ao lado mostra o esboço que fizemos - a qualidade da foto está ruim, porque foi tirada de um celular. Se reparar, vai ver que o site segue os fluxos de telas desse esboço apesar das seções não serem as mesmas.

2ª Etapa - Corte do layout e os textos do site

Nesta etapa dividimos o trabalho em duas partes: O Lucas cortou o layout, eu e o Carlos produzimos os textos. A imagem ao lado mostra como era feita (Google Docs) a produção dos textos. O Lucas finalizou rapidamente o corte do layout e começou a ajudar na produção dos textos. Com todo o conteúdo produzido mandamos para a nossa redatora freelancer, que também concluiu o trabalho em poucas horas.

3ª Etapa - Integração do layout com o Rails

Essa parte foi a mais fácil! Só precisou do Lucas trabalhando sob demanda para o Carlos. Em menos de 1 dia de trabalho foi tudo concluído. Claro, como um bom admirador não poderia deixar de dizer que o Rails ajudou demais o nosso trabalho.

Apesar das “mil maravilhas”, eu e o Carlos tivemos uma pequena discussão: “Usar a página de busca do Google ou a API do Yahoo para fazer as buscas no site?”. Eu, focando sempre em simplicidade, queria usar a página de busca do Google e o Carlos a API do Yahoo. O Carlos acabou me convencendo que iria desenvolver rapidamente e iria ficar muito mais bonita. Tenho que tomar cuidado, acho que sou um fanático por simplicidade… Hehehe!

Apesar de existir a 4ª etapa, foi nessa etapa que lançamos o site e concluímos uma semana de trabalho.

4ª Etapa - Correção dos bugs

Para quem já leu o Getting Real (37Signals) e/ou A Catedral e o Bazar (Eric Raymond) sabe que é melhor lançar uma versão Beta e continuar melhorando, do que lançar uma versão Release e deixar parada. Você acaba moldando naturalmente o software para atender aquilo que ele realmente se propõe, sem funcionalidades X,Y,Z que ninguém usa. Corrigimos alguns bugs que aconteciam na renderização de alguns browsers - minha raiva pelo IE só aumenta -, melhoramos algumas páginas e implementamos alguns detalhes no site.

Já estamos com algumas alterações para fazer no site. Estamos planejando para ver se “aquela semana” aparece. E quero deixar claro que o desenvolvimento do site não acabou e que precisamos da ajuda de vocês para deixa-lo da melhor forma possível. Então, para sugestões, bugs e críticas utilize o nosso contato.

Diversas aplicações têm aparecido para desktop baseadas em tecnologias originalmente desenvolvidas para web. As vantagens?

Multiplataforma: Windows? Linux? Mac? A aplicação será a mesma. Absolutamente a mesma. - a não ser que você não queira isto. Não há a preocupação de desenvolver a interface do seu software em Cocoa, em GTK, Qt ou seja-lá-qual-for-a-biblioteca-de-interface-gráfica.

Recursos: As plataformas trazem consigo recursos e suporte a tecnologias que você levaria anos se fosse implementar sozinho.

Foco: Você se preocupa em trabalhar com o que sabe fazer de melhor. Menos stress, curva de aprendizado razoável, prazos determináveis e dentro da realidade.

Instalação/Desinstalação: Ah, isso os dois também suportam nativamente.

XULRunner

O XUL (pronúncia zúl) é uma linguagem de marcação, semelhante ao DHTML e foi desenvolvido para suportar aplicações do projeto Mozilla. Projetos como o Firefox e o Thunderbird possuem suas interfaces construídas em XUL e outras tecnologias, tais como CSS (apresentação/tema), Javascript (comportamento), DTD (principalmente para a internacionalização) e RDF (descrição do conteúdo).

É relativamente fácil a construção de uma aplicação em XUL para quem está acostumado a codificar HTML. Além disso há uma separação entre a interface e a lógica do software. Uma aplicação cuja interface fosse construída em XUL poderia rodar em Firefox ou qualquer outro navegador baseado no Gecko.

O XULRunner dispensa o browser. Ele é um pacote de execução que permite rodar aplicações XUL+XPCOM standalone. Isto significa que um software que se utiliza desta plataforma pode suportar extensões, temas, plugins, vários protocolos e diversas outras configurações que o Firefox e o Thunderbird suportam.

Exemplos de belos softwares desenvolvidos em XULRunner são o famoso Joost e o emergente Songbird.

Adobe AIR

Batizado inicialmente com o nome de Apollo, o AIR permite portar aplicações Flex, Flash e HTML/JS via engine WebKit (iniciada com o KHTML + modificações da Apple para o Safari + trabalho da comunidade) para o desktop.

O instalador possui 9mb e está disponível no site da Adobe. Uma vez instalado, é capaz de ler os arquivos “.air” das aplicações e instalá-los.

De exemplo, deixo o kuler, o Adobe Media Player e o Ebay Desktop

O ponto mais polêmico no uso do XULRunner ou do AIR é que para cada aplicação é instalada uma nova instância do XULRunner, enquanto que o AIR, é instalado somente uma vez. A principal desvantagem de se ter múltiplas instâncias é o uso de espaço em disco aumentado e a descentralização das atualizações da plataforma. No entanto, você não correria o risco de atualizar o pacote de execução e algumas das suas aplicações instaladas não serem mais compatíveis, o que representaria mais dor de cabeça para o desenvolvedor de cada aplicação.

Bom, estou traduzindo um post do Signal vs Noise que achei muito interessante. Foi colocado em palavras o que pensamos aqui na Milk-it, e claro, nos acrescenta bastante também, mesmo que apenas por saber que estamos no caminho certo.

Pergunte a 37signals: Eu preciso de um designer para embelezar meus projetos?

Edwin escreveu:

Uma coisa que me atormenta frequentemente, é o design da interface do usuário. Eu sou um desenvolvedor web, usando Rails e capaz de produzir HTML, CSS e JavaScript. Então, eu devo estar ápto a produzir interfaces simples. Mas, se você quer uma interface mais estilizada, você provavelmente utilizará programas gráficos e criará belos ícones e logos. Contratar um designer é normalmente caro e pode fazer com que o desenvolvedor perca o poder de decisões de deisgn de epicentro.

Como a 37signals resolve este problema? Vocês tem um designer em full-time trabalhando em um website ou fazendo as maluquices do CSS para criar a interface?

Pensar em designers como alguém que pinta o aplicativo bonitinho no Photoshop é comum, mas é um infeliz erro de conceito. Nós certamente não temos nenhum designer desse tipo. Ao invés disso, nossos designers aplicam seus talentos nos materiais nativos da Web trabalhando diretamente com HTML, CSS, e ocasionalmente códigos Ruby ou JavaScript.

Isto é uma ligeira noção ímpar para muitos dos programadores web. Eles consideram HTML, CSS, e especialmente JavaScript e Ruby de seus domínios. Se designers trabalham com exatamente o mesmo material, como eles são diferentes?

Pense nisso como papel e caneta. Um programador pode usar estas ferramentas para criar diagramas técnicos de bancos de dados e objetos. Um designer pode usar as mesmas ferramentas para criar um layout persiasivo com um fluxo correto.

Quando designers e programadores trabalham com o mesmo material, eles falam a mesma língua. Isto é um modo incrivelmente eficaz de se trabalhar junto (contrasta com artistas falando sobre Photoshop e “cortadores de HTML” tentando adaptar aquilo à Web).

Designers decidem e projetam o fluxo, a ambíguidade, a estrutura da página, os programadores trazem tudo isso a vida conectando ao software. Tudo juntamente com concessões de ambas as partes em como fazer um recurso da forma mais rápida agregando o valor de facilidade.

Então pare de pensar em designers como artistas que trabalham em um universo diferente de belos gráficos e comece a pensar neles como alguém que decide onde, qual elemento de formulário usar, como dividir um recurso entre telas, quais palavras usar, e como tudo isso encaixa em uma experiência coerente.