Dias atrás acabei tendo um pequeno embate no twitter por conta de algo besta: ao testar um sistema integrado ao twitter, percebi que esse aplicativo postou automaticamente uma mensagem no meu perfil e passou a seguir um outro perfil, sem que houvesse uma autorização clara da minha parte.
Ao reclamar de forma bem clara sobre essa postura, um dos desenvolvedores entrou em contato, e no calor do momento troquei umas quatro ou cinco mensagens mal-criadas com ele, explicando meus descontentamento. Mas, até aÃ, quem me seguia já sabia do problema, e provavelmente pensou duas vezes antes de também testar o serviço.
Tudo isso poderia ter sido evitado com uma postura simples: planejar o sistema para que nada fosse realizado na minha conta sem minha expressa e clara autorização. Sou extremamente sensÃvel com sites ou programas que se conectam aos meus perfis virtuais (sejam meus blogs, twitter, ou até meu perfil no MyAnimeList) e realizam atualizações por conta própria sem minha permissão. Muitos provavelmente não veêm problema algum nisso, mas eu não sou o único que encaram quase como uma invasão.
O nascimento de plataformas sociais como twitter, orkut, facebook e outros trouxe um novo conceito na criação de aplicativos para a web: os aplicativos sociais, que utilizam o ambiente das redes sociais para tornar o desenvolvimento mais rápido e integrado. Assim, ao invés de criar todo um site e estrutura interna para criar, digamos, o Colheita Feliz, você pode desenvolver um sistema que utiliza as ferramentas do orkut (cadastro de usuário, segurança, etc.) e agilizar boa parte do desenvolvimento do sistema. Assim, ganha o desenvolvedor (que pode colocar seu sistema dentro de uma rede maior) e ganha o usuário (que possui mais opções de uso dentro da rede).
O problema é que o mal uso dessa integração pode gerar insatisfação com os usuários e até queimar totalmente o filme do desenvolvedor.
Pensando nisso (e em outras ‘mancadas’ que já vi acontecer em outros aplicativos), montei um apanhado de dicas que você, desenvolvedor solitário, empresa ou startup, deveria pensar em seguir antes de liberar seu aplicativo social para o mundo. Não encarem essas dicas como regras gravadas em pedra, mas sim a como a opinião de um desenvolvedor/sysadmin/usuário que tem alguma idéia do que está falando. 
1 РPreocupe-se com a seguran̤a
Regra básica que muitos esquecem: não é porque a rede social já oferece recursos de segurança que você deve esquecer de fazer a sua parte. Sessões que não se encerram, variáveis não declaradas corretamente, recebimento de dados via GET e por aà vai podem ser usados para causar qualquer coisa, desde vantagens dentro de um jogo, como tentativas de invasão e roubo de dados. Não é incomum encontrar casos de senhas e perfis roubados porque alguém usou um aplicativo social que tinha uma falha.
Algumas redes como o Twitter agora permitem autenticação via oAuth, permitindo que seu aplicativo possa se comunicar diretamente com a base de dados do twitter, evitando assim que o aplicativo precise pedir usuário e senha para funcionar corretamente. Todo aplicativo social decente deveria usar oAuth ou soluções similares que a rede social possua.
Leve isso em consideração antes de liberar seu aplicativo para o público. Não há nada pior que ser conhecido como o “cara que desenvolveu um sistema que permitiu o roubo de vários perfis do orkut”.
2 РPreocupe-se com o alto n̼mero de acessos
Algumas redes permitem que você hospede seu aplicativo em um servidor interno, outros exigem que você hospede em um servidor próprio (o mais comum). Nesse caso, parta sempre do principio de que seu aplicativo será um SUPER-HIPER-MEGA-SUCESSO e que BILHÕES DE PESSOAS estarão tentando acessá-lo simultaneamente, e se esforce em programar um algoritmo leve e dimensionar seu servidor para que ele aguente uma grande carga de acessos. Existe uma série de procedimentos que podem (devem!) ser seguidos para otimizar seu código, e isso vai variar do tipo de linguagem que você usará e em quais redes sociais o sistema será usado. Leia sempre todo o tipo de documentação e preocupe-se em usar soluções leves, simples, e que demandem poucos recursos. Vai usar um banco de dados? Estude otimização de queries.
Obviamente, nem sempre é possÃvel estimar corretamente o número de acessos que seu aplicativo vai ter. Nesse caso, lembre-se de manter um código que tenha fácil manutenção e que lhe permita encontar e alterar o maior número possÃvel de ‘gargalos’ na performance.
Uma idéia é você inicialmente lançar o aplicativo como um beta, fechado para um número X de usuários, e a partir daà fechar para novos cadastros. Se o serviço mostrar-se um sucesso e tiver boa receptividade, o que você tem que de fazer é correr atrás de um patrocinador ou investiro para investir em servidores mais potentes, talvez até alguns clusters ou servidores separados para aplicação/banco de dados.
Seu serviço pode ser o máximo, perfeito, revolucionário. Mas se ele não aguenta mais de 10 usuários e vive caindo, ninguém vai querer usar.
3 – Siga as regras e o bom-senso
Descobriu uma forma de fazer o usuário mandar automaticamente milhares de direct messages pelo twitter? Legal, mantenha a idéia pra você. No máximo, seu aplicativo irritará os usuários e será usado por spammers, garantindo que o acesso seja bloqueado e o aplicativo não possa mais ser usado. E provavelmente é você quem vai acabar pagando o pato.
A liberdade que algumas APIs trazem é interessante, e com um pouco de criatividade não é dÃficil criar algo que viole as regras da própria rede social ou careça de um pouco de bom-senso. Não é dificil lembrar do caso NoEscuro, um site de 2007 que permitia que qualquer um postasse em um perfil no twitter, de forma totalmente anônima. O resultado foram centenas de mensagens com difamações, xingamentos, palavrões e toda a sorte de bobagens que só o anonimato na internet permite criar. O site e o twitter foram tirados do ar em poucas horas.
Há uma possibilidade quase infinita de aplicativos que podem ser criados para as redes sociais, desde jogos a sistemas de controle de finanças. Mas não é porque algo é possÃvel que ele é permitido ou bem-visto pela sociedade, e você deve levar isso em consideração antes de planejar seu aplicativo. Se voce não consegue pensar em nada que não vá importunar seus usuários, o melhor é não fazer nada.
"Como assim, me usar para praticar roubos?"
4 РṆo seja intrusivo
E aqui chegamos ao ponto que me levou a publicar essas dicas: aconteça o que acontecer, jamais seja intrusivo. Jamais peça permissão do usuário sem deixar claro o motivo dessa solicitação. Jamais atualize ou faça alterações automaticamente no perfil do usuário se ele não tiver explicitamente solicitado ou autorizado isso. Existem centenas de serviços integrados ao twitter (por exemplo) que periodicamente fazem atualizações automáticas. Mas essa é uma opção do usuário. Ninguém reclama do foursquare ou do formspring ou do tumblr pelas twittadas automáticas a cada atualização: eles reclamam dos usuários que habilitaram essa opção e a deixaram ligada. E essa é uma diferença vital: o errado não é o aplicativo, é o usuário. Ele é o chato que foi lá e deixou a integração ligada.
Se você realmente prefere deixar algumas opções marcadas automaticamente, deixe isso claro para o usuário da melhor forma possÃvel: um aviso em fonte pequena escondido no meio do layout não te isenta de responsabilidades. Use um destaque com cores ou tamanhos diferentes, explicando exatamente para o usuário o que será feito, e permita que o usuário desmarque de forma fácil essa opção.
Há outro ponto a considerar: se o seu aplicativo twitta automaticamente pelos usuários e vários usuários acabam usando a ferramenta, a rede social pode acabar considerando que o volume gigantesco de mensagens iguais sendo postadas é uma forma de spam, e bloquear o acesso do aplicativo à API.
Ao não dar opt-in automático, você se isenta de responsabilidades. Ao questionar o usuário, você evita reclamações posteriores. Lembre-se: em redes sociais, o que realmente acaba importando é o usuário, não o aplicativo. Seu aplicativo pode ser lindo, mas se os usuários o rejeitarem, ele não vai pra frente.
(colaborou @interney)
Comments (3) 
Themocracy