Salvo exceção, você desenvolvedor já foi chamado por um cliente com o seguinte pedido:

“Quero que você desenvolva um aplicativo para mim, que funcione na internet, e que permita publicação, votação e comentários em artigos”.

Designers também costumam ouvir algo do tipo:

“quero que você faça um site para mim. Esse site tem que publicar artigos, permitir que os visitantes votem no melhor e também façam comentários”.

Tendo em vista o que seu cliente pede, você que é desenvolvedor, entrega um site ou um aplicativo?

Responda rápido, se for capaz. Identifique nas 10 alternativas abaixo, quais são sites e quais são aplicativos:

• 1. Gmail
• 2. Google
• 3. Blogger
• 4. Flickr
• 5. Webinsider
• 6. Homepage do UOL
• 7. Camiseteria
• 8. Windows Live Spaces
• 9. Wikipedia
• 10. Apontador

Se você respondeu que os dez são sites, ganhou nota 5. Se você respondeu que os dez são aplicativos, também ganhou nota 5. Mas se você respondeu que os dez são um misto de site e aplicativo, ganhou nota 10.

É isso mesmo. A diferença entre um e outro está cada vez menor e os conceitos estão mais confusos, mas vamos tentar esclarecer um pouco. Com o surgimento da web 2.0, então, o abismo de antes virou uma valeta rasa. Para encurtar o assunto, praticamente todos os sites que usamos hoje têm, por trás, aplicativos que o fazem funcionar.

Vamos tomar como exemplo um prato self-service da internet: um blog. Quando falamos em “criar um blog”, estamos usando vários programas que recebem o que você escreveu, gravam os dados no banco de dados, mostram em ordem descrescente de postagem, filtram por categorias, etc.

Concorda que são programas? E concorda também que um conjunto de programas forma um aplicativo (ou sistema, no jargão da minha época)?

Quando você instala um plugin num blog, você está inserindo um novo programa ao aplicativo já existente, não é mesmo? A questão é que isso tudo melhorou tanto, que esses detalhes técnicos passam despercebidos por nós, a maioria do tempo. Mas continua sendo um conjunto de programas (um aplicativo).

Então vem a pergunta: é um site ou um aplicativo?

A diferença está no que o visitante do site (que usa o aplicativo) percebe e o que o seu cliente (que paga pelo site) determina. O ideal é que o visitante do site (que usa o aplicativo) tenha a sensação de estar usando um site e que seu cliente (que paga pelo site) tenha a oportunidade de definir todas as regras do aplicativo; por mais óbvias que sejam.

Não entendeu direito? Vamos analisar as duas visões aparentemente antagônicas.

Se você lançar um aplicativo na internet, provavelmente ninguém vai querer usá-lo. Aplicativos são conhecidos por serem complicados, precisarem de manual e treinamento. Ou ambos. Cada aplicativo tem um visual diferente. Já um site é outra coisa. Bem melhor! A simples possibilidade de usar um serviço baseado no browser dispensa até treinamento. Quer um exemplo? As suites online de escritório: Google Documents, Editgrid, Zoho, etc. Você precisou de treinamento para usar esses sites (aplicativos)?

Para uma empresa, que vantagem, hein! Além do gerenciamento centralizado, temos uma interface comum que qualquer pessoa está acostumada a ver num webmail, grupo de discussão ou portal de notícias. Isso é ter a sensação de usar um site. O que fala mais alto aqui é o lado psicológico de quem usa.

Por outro lado, toda essa simplicidade aparente não descarta a necessidade de regras, validações, projeto de banco de dados, segurança, log de erros, etc. Isso tudo faz parte do projeto de um aplicativo, certo?

Então, vem novamente a pergunta: é um site ou um aplicativo?

Você, como desenvolvedor, continua fazendo programas que recebem dados, faz a validação dos campos, grava ou busca informações numa base de dados e entrega uma resposta. Igualzinho como fazia em aplicações desktop ou centralizadas. O que mudou foi a forma de apresentar o resultado ao visitante (que usa o aplicativo).

Por esse motivo é que nós, que somos desenvolvedores de aplicativos, não conseguimos mais trabalhar sozinhos sem um designer para dar aquele visual de site ao nosso aplicativo.

Ou, como diriam os designers, não seria possível entregar o site sem o programador para inserir todas as regras de funcionamento e processamento dele. Um não vive mais sem o outro.

E é muito bom que seja assim. Esse é o motivo da enxurrada de frameworks e técnicas para separar a lógica de negócio da apresentação dos dados. Como podemos dizer no popular, “cada macaco no seu galho”.

Portanto, para o visitante (que usa o aplicativo), deixe o designer apresentar um site. Ele se sentirá bastante à vontade. Afinal, um site é fácil de usar e bonito de se ver.

Mas para o cliente que pediu o site (e que paga pelo seu serviço) desenvolva um aplicativo. É esse cliente quem vai definir aquele monte de regras, que perfil de usuário pode fazer o quê, qual a política de segurança, qual a complexidade das interações, aprovar seu modelo de informações, pagar pelo seu serviço, etc.

Tenho certeza que ambos ficarão felizes com a simplicidade do site e o controle do aplicativo. Cada qual com seu pedaço. E você, com um bom case em seu portifólio. [Webinsider]
.

Vinicius Assef

Vinicius Assef (viniciusban@gmail.com) é desenvolvedor de aplicações. Trabalha principalmente com mainframe e contribui com projetos voluntários para a internet.