Tornando reais suas aplicações para a Web

Publicado em por

Introdução (talvez você não precise desta parte)

Todos já notamos que vender aplicações em caixas bonitas é coisa do passado. Mesmo que este tipo de distribuição de software se mantenha por um bom tempo, mesmo que sistemas operacionais precisem ser entregues em caixas bonitas daqui a 30 anos, ainda assim é passado.

O novo modelo de distribuição coloca os softwares para serem utilizados na Web, dentro do navegador(por enquanto), com conexões banda-larga e CPUs ultra poderosas fica fácil.

Este texto está sendo escrito em uma aplicação chamada Writely que roda na web e, para meu uso, tem muitas vantagens sobre um processador de texto que rode localmente, como Microsoft Word ou BrOffice.org Writer. Para citar três destas vantagens: eu posso acessar o texto de qualquer lugar, posso escrever o texto em conjunto com outras pessoas simultaneamente, não precisei instalar uma suite de aplicativos que custa quase R$:1000,00 e iria consumir processamento e memória RAM do meu computador pra sempre.

O objetivo deste texto é traçar algumas dicas para pessoas envolvidas no desenvolvimento de aplicações para esta Nova Web (perdão pelo jargão, mas não consigo achar nada mais adequado). Não é focado apenas em programadores, designers, gerentes de projeto ou qualquer outro perfil profissional, pode ser usado inclusive para projetos não-Web e não-programação.

Implemente o princípio KISS para desenvolver suas aplicações (talvez você não precise desta parte também =)

Para quem não sabe, KISS significa: Keep It Simple Stupid, ou Mantenha-o Simples Estúpido em bom português. É um princípio inicialmente criado para definir o desenvolvimento de softwares do mundo UNIX, onde vários programas simples e altamente especializados conversam entre si para realizar tarefas de qualquer tamanho, grandes ou pequenas, simples ou complexas. Posteriormente este princípio foi portado para outras áreas, como design, arquitetura da informação e web design.

KISS significa não perder recursos com itens inúteis, seja o recurso em questão espaço, tempo, processamento. Significa manter somente o necessário para o bom funcionamento da aplicação e experiência do usuário.

Aparentemente o princípio KISS foi esquecido em softwares como Microsoft Word, Microsoft Excel, Microsoft Power Point, Microsoft Outlook (este é o inferno dos usuários), BrOffice.org (derivado do OpenOffice.org), e-Mule, KaZaA, Microsoft Messenger (MSN, Live, Windows), e vários outros. A Microsoft não é a única a pecar em não utilizar o KISS, quase todos os softwares da "geração passada" são complicados demais.

Com o desenvolvimento de aplicações para a Web, KISS foi relembrado, aplicações especializadas, objetivas, que fazem "só isso" são comuns. O Google Calendar não manipula e-mails, o Ta-Da List nem sabe o que é uma imagem, o Bloglines não navega na Web (mesmo porque ele está dentro dela).

Mantenha a equipe pequena

Muitas pessoas em equipes paquidérmicas gera confusão, o trabalho sempre fica embolado no meio de campo. Mantenha a equipe pequena, as coisas serão feitas com maior agilidade caso não sejam necessários 4 e-mails de aprovação para cada ícone da aplicação.

Evite reuniões

A maior parte das reuniões pode ser evitada com e-mails e conversas por mensagem instantânea. As reuniões só fazem você perder um precioso tempo e ainda quebram o seu fluxo de trabalho diário. Além disso, elas se desviam do caminho proposto com a mesma facilidade que um brasiliense dirigindo nas ruas de São Paulo.

Não perca tempo prevendo o mundo real, enfrente-o

Não perca tempo com coisas que representam o mundo real, como gráficos, planilhas, especificações, testes; enfrente o mundo real desenhando a interface, programando o software e lançando-o.

Se você não perde tempo com tarefas inúteis pode trabalhar diretamente no que é real e lançar a aplicação mais rapidamente.

Comece por algo palpável (não se esqueça: enfrente o mundo real!)

Seus investidores e utilizadores preferem ver uma janela de terminal com toda a saída de um banco de dados orientado a objeto ou algumas telas da interface do programa com as funcionalidades básicas implementadas?

O Wufoo, um construtor de formulários para a Web, se manteve meses "em alta" na comunidade de desenvolvedores simplesmente com um "demo", não gerava uma linha de código, porém, deixava você criar e arrastar campos pela tela. Se a equipe do Wufoo tivesse começado com a infra-estrutura ao invés da interface você acha que eles teriam tanto sucesso?

Para notar isto, basta ver o fantisy rpg, não há nada na página do projeto, caso houvesse pelo menos as imagens dos personagens, as pessoas se interessariam com maior facilidade.

Lance logo e atualize sempre

Você não deve perder tempo tentando prever o que os usuários vão aprovar ou não em seu programa. Não gaste tempo tentando cobrir todas as falhas possíveis do software para só então publicá-lo.

Um software na Web não precisa aguardar um ano para ser atualizado, não precisa de nomes de versão ininteligíveis: Internet Explorer 6.0.2900.2180.xpsp_sp2_rtm.040803-2158? Mozilla Firefox 1.5.0.4? Isso é passado. [1]

Se você lança logo, pode receber respostas dos usuários e retirar os recursos indesejados no mesmo dia, assim como inserir recursos solicitados.

Os softwares têm potencial para ter atualizações rápidas e transparentes aos utilizadores, seu método de desenvolvimento deve conseguir atender a esta demanda.

<update datetime="2006-07-27">

Escalabilidade é sua amiga

Se o software será atualizado constantemente, você precisa poder incrementar novas funcionalidades e recursos com facilidade, se a cada atualização for necessário reescrever todo o código-fonte, suas atualizações não serão tão rápidas quanto poderiam.

Lembre-se do princípio KISS aplicado ao mundo UNIX, divida sua aplicação em componentes que conversem entre si. Com sua aplicação componentizada você poderá alterar o fluxo da comunicação, ou modificar os componentes individualmente, com bastante facilidade.

</update>

Não se preocupe com problemas do futuro

Não se preocupe se seu servidor não suporta 400.000 acessos simultâneos, deixe este problema ser resolvido quando você tiver este número de acessos, concentre-se em resolver os problemas do presente.

Não perca tempo com problemas que surgirão no futuro, você não precisa cobrir o universo, é por isso que seu software está na Web, você pode cobrir apenas a área necessária. Deixe as preocupações de compatibilidade futura de lado.

Faça menos que a concorrência

Costumava-se acreditar que para vencer um concorrente, você deveria fazer mais que ele. Se o software dele tem 10 funcionalidades, o seu deve deve ter 15 ou 20. Se ele tem 60% de qualquer coisa, você deve ter 80%. Não faça isso, esta é uma prática antiga que já não funciona mais.

Sua aplicação deve fazer menos que a dos concorrentes, deve atingir um ponto objetivamente, sem deixar dúvidas para o usuário sobre a função do seu software.

Menos significa:

  1. Menos janelas de opções e preferências.
  2. Menos elementos na interface.
  3. Menos formulários de cadastro com menos campos para preenchimento.
  4. Menos cliques.
  5. Menos instalações de plug-ins.
  6. Menos avisos.
  7. Menos telas.
  8. Menos burocracia.

O meebo ganhou o mundo por ser mais simples que seus concorrentes, basta entrar no site, digitar login e senha do serviço de mensagem instantânea desejado e pronto, você está conectado, sem cadastros, sem avisos, sem configurações, sem alteração de permissões aqui e ali, sem e-mails de confirmação.

Conclusão (gancho para atualizações =)

Este texto também segue a filosofia do publique logo e atualize sempre. Foi escrito rapidamente e será atualizado constantemente. Não coloquei sequer as tags de semântica XHTML necessárias, isso será feito nas atualizações.

Links:

Observações:

  • Boa parte deste texto foi escrito com base em algumas lições da 37signals.
  • É óbvio que estas dicas não são imutáveis e não devem ser seguidas à risca, cada projeto tem suas peculiaridades. Eu sei bem que sistemas de internet banking e gerenciadores de usinas nucleares não devem ser desenvolvidas na doida =)
  • [1] Sei que usei como exemplo programas que não poderiam rodar na Web, mas foi só para ilustrar como nomes de versão podem ser confusos.