Construindo uma rede social

[João Batista Neto 448]

Bom pessoal, a ideia aqui é construir um "mix" de uma rede social (estilo Twitter) com um sistema de discussão (estilo Google Wave).

 

Para conseguirmos construir essa aplicação, seguiremos 3 passos

 

1. Análise de Requisitos.

2. Arquitetura/Modelagem.

3. Engenharia.

 

Esses três passos são, necessariamente, sequenciais e o sucesso de um depende do bom planejamento do anterior e, para conseguir desenvolver nossa aplicação, vamos conversar com ela em todos os passos. A idéia é que todos participem do processo completo, sugerindo, questionando, discutindo, enfim, movimentando idéias.

 

[João Batista Neto 448]

Análise de Requisitos:

 

Análise de requisitos, segundo a Wikipédia:

Análise de Requisitos é o estudo das características que o sistema deverá ter para atender às necessidades e expectativas do cliente.

 

Cada funcionalidade demandada pelo cliente deve ser analisada para verificar os possíveis impactos no desenvolvimento das demais funcionalidades do sistema, e verificado em conjunto com a equipe de desenvolvimento se as necessidades tecnológicas para a sua implementação estão disponíveis.

 

O que é a aplicação ?

Como ela trabalha ?

Ela realmente precisa fazer isso ?

 

Apesar desse primeiro passo ser muito importante, muitas vezes ele acaba desencadeando uma série de recursos "gordurentos" que farão com que nossa aplicação fique pesada, lenta e demore para ser construída e, muitas vezes, com coisas que jamais serão efetivamente utilizadas; Por isso, vamos utilizar nesse passo, um dos princípios fundamentais no desenvolvimento de software, vamos manter isso simples (KISS).

 

Logo acima, eu disse que essa aplicação será um mix de duas aplicações, o que significa que, para tomá-las como base, precisamos ver o que elas fazem:

 

Twitter:

Sistema de mensagens simples, onde o usuário posta uma mensagem curta e todos os seus seguidores podem lê-la e repassá-la para seus "seguidores". Talvez, o grande responsável pelo sucesso do Twitter é o fato dessa aplicação ter levado a sério o princípio KISS; Não existe gordura, não existem mais recursos do que você realmente precisa.

 

Google Wave:

Sistema de discussão, onde cada "wave" é destinada à um grupo escolhido por quem a abre, possui tantos recursos que nem com muito ânimo, seria possível utilizá-los em uma única "wave". É uma ferramenta gordurenta, pesada e, muito provavelmente por isso, não tem o sucesso que era esperado para uma ferramenta Google.

 

Nossa Ferramenta:

Assim como o Twitter, teremos um sistema de mensagens curtas. O usuário postará uma mensagem e definirá quem a verá, utilizando sua lista de contatos, porém, assim como o Google Wave, as mensagens poderão ser respondidas em linha, como uma thread em um fórum.

 

Não teremos um "retweet", usaremos a ideia utilizada pelo Google Wave e compartilharemos uma mensagem com outras pessas que, por sua vez, poderão compartilhar com outras pessoas de suas listas de contatos; Perceba que seguiremos mensagens e não pessoas.

 

Teremos um cadastro simples de usuário, apenas com nome (identificador único do usuário), nome real, email e senha. Como não precisaremos de mais nenhuma informação, não pediremos mais do que o estritamente necessário.

 

Após cadastrar-se, o usuário terá em sua "home" uma interface de usuário bem simples:

 

1. Caixa de texto simples, no topo, para postagem de novas mensagens:

1.1. O usuário verá uma caixa de texto simples, onde poderá postar uma nova mensagem.

 

2. Botão "Compartilhar":

2.1. O botão "Compartilhar" permitirá que, a qualquer momento, seja possível adicionar um novo participante à discussão, mesmo que o participante não seja aquele que iniciou a mesma, ou seja, o compartilhamento de discussão poderá ocorrer em N níveis, eu compartilho com o Fulano que compartilha com o Beltrano.

2.2 Quando um participante for adicionado à uma mensagem, ele será alertado sobre o convite e poderá aceitá-lo ou não.

 

3. Botão "Remover Compartilhamento":

3.1. Caso seja necessário remover o compartilhamento de algum participante, o botão "Remover Compartilhamento" fará com que ele deixe de poder visualizar e participar da "thread".

 

4. Botão "Bloquear Participação":

4.1. O botão "Bloquear Participação" permitirá que um participante possa acompanhar a discussão, porém ele não poderá responder nenhuma mensagem.

 

5. Lista de mensagens que está "seguindo":

5.1. As mensagens, na "home" serão exibidas de forma simples, apenas a mensagem original.

5.2. Para responder uma mensagem, o usuário terá um botão para expandir a mensagem e, assim, ver todas as respostas postadas.

5.3. Todas as respostas de uma mensagem seguida poderão ser respondidas, independentemente da ordem. Ou seja, se existirem 10 respostas e o usuário quiser postar uma mensagem para a 2ª resposta ele poderá.

 

 

Não teremos esses editores "rich", não permitiremos postagem de imagens, não teremos "gadgets", não teremos frescura; Seguiremos o modelo do Twitter e ficaremos simples, práticos e absolutamente sem gordura.

 

Então, para finalizar o primeiro passo, fica aberta a discussão sobre:

 

1. O que a aplicação deve fazer.

2. O que deve ser considerado gordura e, consequentemente, a aplicação não deve fazer.

 

Todos poderão dar sua opinião até o dia 30 de Julho, sexta-feira.

 

PS:

 

Pessoal, a participação de todos é fundamental.

 

Constantemente, tentamos fazer o que o slogan do iMasters promove que é "Movimentar ideias" mas, por algum motivo, ninguém participa.

 

Essa aplicação só será construída se vocês participarem, movimentando suas ideias, dizendo o que é legal e o que não é.

 

Temos condições de construir uma aplicação legal, então, espero que digam o que acham legal e o que não.

 

;)

[Daniel Ribeiro 4]

Primeiramente, @João Batista Neto, preciso parabenizá-lo pela maravilhosa iniciativa. O que você disse sobre a movimentação de ideias e a quase certa não-participação da comunidade é, infelizmente, verdade. Vamos tentar mudar isso, dessa vez. No que depender de mim, vamos pra frente.

 

Sobre a aplicação, vamos às primeiras considerações:

 

1. O que a aplicação deve fazer

 

Devemos gastar a maior parte de nosso tempo nesta fase, ao meu ver. É aqui que enxugaremos as ideias abstratas e generalizadas, e evitaremos que a coisa comece a, como você mesmo disse, João, engordar demais. No que se refere à utilidade da aplicação, é evidente que batemos em um ponto crítico, o fato de que já existem diversos projetos com o mesmo propósito nosso e isso, por si só, já nos deixa um passo recuados na corrida pelo desenvolvimento único e eficiente.

 

Há pouco falaste, no tópico inicial mesmo, sobre a ideia de fazer com que os usuários compartilhem mensagens e não perfis. Concordo com essa ideia, mas quando chegamos nessa proposta, devemos tomar muito cuidado para perceber as falhas de conceito que estamos levantando.

 

1. Até que ponto nossa aplicação será diferenciada de um Fórum de Discussões?

2. Qual a real funcionalidade que a aplicação irá proporcionar que a diferencie das demais existentes no mercado?

 

É evidente que, a partir da ideia de um modelo protótipo, estamos limitados aos conhecimentos e horizontes de seus desenvolvedores, mas isso não significa que não tenhamos capacidade de desenvolver algo realmente interessante.

 

2. O que deve ser considerado gordura e, consequentemente, a aplicação não deve fazer

 

Acho que devemos nos indagar sobre os cortes de projeto mais a frente do desenvolvimento. Uma das Metodologias Ágeis mais difundidas atualmente é o SCRUM, que podemos definir rapidamente como um estilo de gerenciamento de projetos desenvolvido para solucionar alguns problemas de desempenho e resultados. Nessa metodologia, dividimos o projeto em sprints, que demandam um Sprint Master, ou seja, uma pessoa responsável por definir o que será feito e o que não será feito.

 

Nesse sentido, em cada início de sprint, é realizada uma reunião de planejamento, onde os desenvolvedores se encontram com os clientes, neste caso, os usuários dessa aplicação, para que as ideias sejam podadas e o desenvolvimento possa continuar com o fluxo desejado. É frequente termos reuniões de emergência, no meio do desenvolvimento do projeto, em que definimos que algumas tarefas devem ser cortadas do planejamento do projeto, por falta de coesão com relação ao próprio projeto ou, até mesmo, falta de tempo.

 

Neste caso, creio que devemos focar o início do desenvolvimento com as ideias de base que já estão sendo discutidas, e agendar reuniões com uma periodicidade definida para podarmos a ideia melhor, como na metodologia SCRUM. É evidente que, neste caso, nós, os desenvolvedores, iremos simular os clientes, por termos experiência sobre a necessidade do usuário com relação a este tipo de aplicação.

 

 

A princípio é isso, como eu disse, vamos "digerindo" melhor a ideia e, de acordo com a demanda do projeto, podando as soluções para alcançarmos o objetivo final.

[Guustavo0 0]

Olá,

 

achei a ideia super interresante, tanto que criei meu cadastro no site por causa dela(nunca tinha entrado no forum, entrei hoje achei muito conteudo super bem explicado e aproveitei e fiz meu cadastro), faz pouco tempo qe mecho com PHP e MySQL, sei pouca coisa mas se precisar de ajuda em algo, ficarei lisongeado em ajudar, aprenderia muita coisa com os profissionais que aqui estão :D

 

Incentivo essa ideia,

[João Batista Neto 448]

Todos poderão ajudar, Gustavo, mesmo não sendo programador.

 

Existem várias áreas, fundamentais, para o desenvolvimento de software.

 

Neste tópico, vamos discutir sobre o que deverá ser a ferramenta e, para isso, não é necessário ser desenvolvedor, basta que você já tenha tido alguma experiência com alguma "rede social" e, assim, possa ajudar dizendo o que é legal e o que não é legal.

 

Todas as áreas de desenvolvimento poderão participar, por exemplo, nesse momento, temos um tópico em Design Geral para o desenvolvimento de um logo

[João Batista Neto 448]

o fato de que já existem diversos projetos com o mesmo propósito nosso e isso, por si só, já nos deixa um passo recuados na corrida pelo desenvolvimento único e eficiente.

 

Pelo contrário, é justamente a existência de vários projetos, alguns de sucesso, que nos deixa um passo a frente; Se a comunidade iMasters participar do desenvolvimento, teremos uma equipe, multidisciplinar, capaz de contribuir com ideias, experiências e com suas especialidades e, assim, desenvolver uma ferramenta melhor do que as já existentes, boa para si próprio e para toda a comunidade.

 

Perceba que, ainda não temos um projeto.

 

-- Somos, nesse momento, o cliente; Temos uma necessidade; Precisamos de uma ferramenta para resolver nosso problema. --

 

Todos trabalhamos, de alguma forma, com desenvolvimento, seja ele o design de um logotipo, um software desktop ou uma aplicação web.

 

Nosso problema ?

 

Precisamos estreitar as relações entre as equipes de desenvolvimento e o cliente.

 

Quantas vezes, durante o desenvolvimento de alguma coisa, um cliente liga perguntando-lhe sobre o produto ?

Quantas vezes, durante o desenvolvimento de alguma coisa, você liga para seu cliente, mancando uma reunião ?

 

Quanto tempo perdemos com reuniões e telefonemas ?

 

Há pouco falaste, no tópico inicial mesmo, sobre a ideia de fazer com que os usuários compartilhem mensagens e não perfis. Concordo com essa ideia, mas quando chegamos nessa proposta, devemos tomar muito cuidado para perceber as falhas de conceito que estamos levantando.

 

1. Até que ponto nossa aplicação será diferenciada de um Fórum de Discussões?

2. Qual a real funcionalidade que a aplicação irá proporcionar que a diferencie das demais existentes no mercado?

 

Se conseguirmos desenvolver uma ferramenta onde, nossos clientes são adicionados à uma mensagem, além de registrar as conversas feitas, evitando-se assim "disse-não-disse", trazemos o cliente para mais perto de nós, fazemos ele interagir com o produto.

 

Porém, da mesma forma que podemos adicionar um cliente à uma mensagem, podemos adicionar toda uma equipe de desenvolvimento, muitas vezes em posições geográficas diferentes e, assim, ter um brainstorm que ficará registrado.

 

Muitas vezes, temos vários níveis de profissionais em várias áreas; E se esses profissionais tiverem uma ferramenta em que podem conversar entre si ? Compartilhar suas experiências.

 

Porque se um profissional da equipe tiver uma dúvida, não pode utilizar a mesma ferramenta para discutir um determinado tema com a própria equipe ?

 

Quando temos uma ferramenta que incentiva a comunicação, promovemos um bem comum, para os desenvolvedores, para as empresas, para os clientes e para o produto.

 

Qual a diferença entre a ferramenta e um fórum de discussões ?

 

Basta olhar para os fóruns iMasters que veremos uma grande diferença:

 

1. Temos vários fóruns de várias áreas.

2. Cada fórum de cada área possui várias threads.

3. Talvez eu me interesse apenas por 1 ou 2 threads de cada fórum.

 

Porque tenho que seguir todo um fórum, com várias threads que não me interessam ?

Porque não posso "seguir" apenas as threads que me interessam, mesmo que estejam em vários fóruns diferentes ?

 

O formato das respostas poderá ser sim, semelhante a um fórum, mas o conceito é outro.

 

Esse tópico é para nós, clientes, discutirmos sobre o que realmente precisamos e o que não precisamos para, somente então, termos um projeto.

 

Ação Coletiva

Ação coletiva, é a busca da realização de interesses comuns por mais de uma pessoa. É um termo que possui formulações teóricas em muitas áreas das ciências sociais.

 

[João Prado 64]

Primeiramente parabéns para iniciativa João.

 

Deixarei aqui alguns pontos a definir sobre como vai ser a ferramenta.

Vamos lá!

 

 

1º - Como será a interação entre os usuários?

 

• Será uma ferramenta ao estilo do Orkut, onde existem vários tipos de informação a se disponibilizar, um completo álbum de fotos, etc.
• Será uma ferramenta ao estilo de um fórum, com poucas informações pessoais e apenas uma foto.
• Um mix entre ambos, adicionando áreas necessárias e retirando outras visando uma melhor produtividade da ferramenta.

2º - Como será a interface do usuário?

 

• As páginas terão uma visualização completa, como amigos, mensagens, etc.
• As páginas terão uma visualização simples, onde os membros verão apenas mensagens, como o Twitter (não utilizo mas pelo que vejo é assim).

3º - Como será o visual da aplicação?

 

• Bonito e interativo, visando atrair o usuário através de sua beleza e interação com o mesmo.
• Simples e funcional, visando fixar o usuário a ferramenta pela sua simplicidade e funcionalidade.

4º - Nome?

 

Um dos pontos mais importantes, deve ser definido para que se possa criar um logotipo e até um slogan.

 

 

5º - Conteúdo?

 

Que tipo de conteúdo será focado na aplicação?

 

 

 

 

 

Sugestões

 

- Acho que para facilitar a vida do usuário, poderiam separar-se as mensagens em grupos, como programação e design, por exemplo.

 

 

Teremos um cadastro simples de usuário, apenas com nome (identificador único do usuário), nome real, email e senha. Como não precisaremos de mais nenhuma informação, não pediremos mais do que o estritamente necessário.

- Acredito que o cadastro deverá ser mais elaborado, com mais requisições de informações, a fim de evitar spam.

 

 

Nossa Ferramenta:

Assim como o Twitter, teremos um sistema de mensagens curtas. O usuário postará uma mensagem e definirá quem a verá, utilizando sua lista de contatos, porém, assim como o Google Wave, as mensagens poderão ser respondidas em linha, como uma thread em um fórum.

 

Não teremos um "retweet", usaremos a ideia utilizada pelo Google Wave e compartilharemos uma mensagem com outras pessas que, por sua vez, poderão compartilhar com outras pessoas de suas listas de contatos; Perceba que seguiremos mensagens e não pessoas.

 

Teremos um cadastro simples de usuário, apenas com nome (identificador único do usuário), nome real, email e senha. Como não precisaremos de mais nenhuma informação, não pediremos mais do que o estritamente necessário.

Uma ferramenta semelhante é o Formspring, utilizado por muitas pessoas hoje em dia. É um sistema onde um faz uma pergunta ao outro, e este tem a opção de responder.

Nunca utilizei, mas pelo que já vi é uma ferramenta de resposta única, sem direito a réplica. Acredito que nossa ferramenta deva permitir mais respostas, a fim de estimular a troca de idéias entre os participantes.

 

 

 

Por enquanto acho que é isso, com o tempo e interação vamos adicionando alguns pontos no projeto.

 

Abraços

[João Batista Neto 448]

1º - Como será a interação entre os usuários?

 

Uma rede social define vários tipos de ligações entre seus participantes.

 

Imagine que somos uma empresa de desenvolvimento com clientes e profissionais.

 

Um cliente pode ter um ou mais projetos que pode estar com um ou mais desenvolvedores.

 

A ideia é estreitar o relacionamento entre os nós da rede, promover a colaboração entre eles.

 

2º - Como será a interface do usuário?

 

Só teremos condições de pensar na interface de usuário quando tivermos um escopo do que será de fato a ferramenta.

 

3º - Como será o visual da aplicação?

 

• Bonito e interativo, visando atrair o usuário através de sua beleza e interação com o mesmo.
• Simples e funcional, visando fixar o usuário a ferramenta pela sua simplicidade e funcionalidade.

Nada impede que ela seja simples, funcional, porém bonita e interativa; É nesse ponto que o pessoal de design poderá colaborar efetivamente.

 

4º - Nome?

 

Um dos pontos mais importantes, deve ser definido para que se possa criar um logotipo e até um slogan.

 

De fato, será necessário ter um nome, acredito que o pessoal de consultoria e brainstorm poderá colaborar nesse ponto.

 

5º - Conteúdo?

 

Que tipo de conteúdo será focado na aplicação?

 

Comunicação !!!

 

 

Sugestões

 

- Acho que para facilitar a vida do usuário, poderiam separar-se as mensagens em grupos, como programação e design, por exemplo.

 

A ideia de se criar grupos pode ser interessante.

[João Prado 64]

Entendido.

 

 

A idéia dos grupos é para separar o conteúdo, facilitando a busca do usuário pelo que lhe interessa.

 

Também vejo a possibilidade de haver uma interação entre esses grupos, apenas não sei exemplificar de que forma.

[Daniel Ribeiro 4]

Precisamos estreitar as relações entre as equipes de desenvolvimento e o cliente.

 

É exatamente essa a proposta da metodologia SCRUM. Na minha experiência, onde trabalho, mantemos contato constante com o cliente, seja em reuniões periódicas, pra digerir as ideias do sprint e redirecionar o fluxo do desenvolvimento, seja por telefone ou e-mail, para acertar detalhes sobre a aplicação.

 

É essa a mentalidade que temos que ter.

 

E, pra falar a verdade, visto que, no momento atual, estamos simulando a posição de cliente, essa tarefa será facilitada.

 

Vejo que a coisa está andando no caminho certo de que conversamos anteriormente, João.

 

Creio que agora devemos aguardar maior participação da comunidade - principalmente daqueles usuários que sabemos que ainda vão participar - para direcionarmos melhor a ideia.

[Will Fernando 2]

tem uma rede social que começei a usar a pouco tempo , bem bacana, eu gostei e passei para algums amigos e logo viro sucesso pela regiao, é neste estilo mesmo da planejada aqui, simples pratica elegante e sem muita frescura =] deem uma olhada

 

http://www.plurk.com/WillFernando

 

http://www.plurk.com/API/

 

valwww

[Guustavo0 0]

Alem de abordar o publico comum, a rede poderia ter uma opção para os que "sabem mais" por exemplo para os programadores,designer e etc, para eles exporem seus trabalhos, como o

 

http://www.deviantart.com/

 

ficaria legal, algo que não vejo em muitos lugares :lol:

[Matias Rezende 50]

Primeiro, parabéns João Batista. Excelente iniciativa. Pode contar com o meu apoio, como já te falei ontem.

 

Pelo que compreendi, a idéia da rede social é, em resumo bem resumido, um Google Wave magro.

 

Categorias

- Não seria mais interessante trabalhar com tags, podendo marcar mais de uma tag para cada mensagem?

 

Sugestão de recurso:

 

- Possibilidade do criador da mensagem excluir mensagens postadas pelas outras pessoas (owner da mensagem)

Porque?

Imaginem que, por exemplo, eu criei uma mensagem e compartilhei com 10 pessoas. 1 destas pessoas compartilhou com outras 10 pessoas, sendo que 1 delas "não gosta de mim". Esta pessoa vai lá e posta:

Carlos, você é um PNC, FDP, VTNC, #$#@# ..

 

Esta mensagem vai estragar todas as outras. Então, seria interessante que o criado da mensagem pudesse excluir alguma outra mensagem.

 

- Permissão na mensagem

Seria, na verdade, uma união dos recursos Bloquear Participação e Remover Compartilhamento. Seria definido 4 tipos de permissões:

• Nenhuma permissão (não pode ler nem postar)
• Permissão de leitura (pode ler mas não pode postar)
• Permissão de leitura e escrita (pode ler e pode postar novas mensagens, mas não pode compartilhar com outras pessoas)
• Permissão total (pode ler, pode postar novas mensagens e pode compartilhar com outras pessoas)

Também seria interessante definir três tipos de mensagens:

• Públicas (todos podem ver)
• Protegidas (todos meus contatos podem ver)
• Privadas (somente os que eu quiser compartilhar)

Seria algo mais ou menos assim... Não sei se consegui passar a idéia corretamente, mas é uma idéia.

 

E vamos continuar participando

 

Carlos Eduardo

[João Batista Neto 448]

Na verdade, acho que a possibilidade disto acontecer (usuário enviar um monte de mensagem uma atrás da outra) não será muito grande, porque as pessoas terão que ser CONVIDADAS a participar da mensagem.

Exatamente, Carlos.

 

Pessoal, não podemos engordar nossa ferramenta.

 

Pensem que somos uma empresa de desenvolvimento de qualquer coisa, o nome dessa empresa é "Empresa"

 

Temos um cliente que compra um produto chamado "Projeto"

 

Porque nós, como empresa, compartilharíamos uma mensagem com um flooder se tudo o que queremos é fazer com que o projeto seja desenvolvido da forma mais rápida e eficaz possível ?

 

Porque o cliente compartilharia uma mensagem com um flooder se tudo o que ele quer é ter o produto comprado pronto ?

 

A probabilidade de flood é mínima, para não dizer inexistente, já que todos trabalham para um objetivo comum, ter o produto do cliente finalizado.

[Will Fernando 2]

- Possibilidade do criador da mensagem excluir mensagens postadas pelas outras pessoas (owner da mensagem)

 

Porque?

Imaginem que, por exemplo, eu criei uma mensagem e compartilhei com 10 pessoas. 1 destas pessoas compartilhou com outras 10 pessoas, sendo que 1 delas "não gosta de mim". Esta pessoa vai lá e posta:

 

Quote

Carlos, você é um PNC, FDP, VTNC, #$#@# ..

 

Esta mensagem vai estragar todas as outras. Então, seria interessante que o criado da mensagem pudesse excluir alguma outra mensagem.

ainda na ideia do Pedro Matias .. e caso alquem comesar a floodar ??

fica disparando 100 mensagens "Baby baby baby .. onnnnnnnn " .. .. beleza blokeia ele exclui as mensagens .. ele vai no proximo e começa a flooda dnovo ¬¬ *isso enxe o saco

 

teria que ter alguma forma de "blokeio" ou advertencia automatico para os flooders

 

valww

[João Prado 64]

teria que ter alguma forma de "blokeio" ou advertencia automatico para os flooders

Ou um limite de tempo entre uma mensagem e outra.

 

Por isso eu acho que deve pedir mais informações no cadastro, para confirmar a identidade do indivíduo. Assim, não evita, mas diminui MUITO os spammers.

[h4v3st 1]

João parabens pela iniciativa, é um belo projeto.

Mas só para entender, no caso todas as mensagens que eu escrever eu terei que selecionar um grupo de pessoas que poderão ler estas mensagens ? Fulano pode ver e beltrano não, seria isso ?

 

Temos inúmeras tipos de redes sociais, temos que pensar em algo diferente para que chame atenção.

[João Batista Neto 448]

Mas só para entender, no caso todas as mensagens que eu escrever eu terei que selecionar um grupo de pessoas que poderão ler estas mensagens ? Fulano pode ver e beltrano não, seria isso ?

O ato de compartilhar fará com que o novo participante possa ver todas as mensagens anteriores e todas as próximas, isso significa que você compartilhará uma "thread" apenas uma vez.

[Matias Rezende 50]

Na verdade, acho que a possibilidade disto acontecer (usuário enviar um monte de mensagem uma atrás da outra) não será muito grande, porque as pessoas terão que ser CONVIDADAS a participar da mensagem. Ou seja, eu posso ser um spammer, mas só vou conseguir postar naquela mensagem se alguém compartilhar comigo.

 

A questão do spammer acontecerá mais com usuários que irão se cadastrar para enviar mensagens de spam para os outros. E para evitar isto, faço outra sugestão (não sei se já foi feita, mas...):

 

Só será possível se cadastrar mediante convite, e cada pessoa terá um limite de convites a serem enviados.

 

Carlos Eduardo

[David Ramires 1]

Opa boa idéia, parabéns pela iniciativa! vou ler todos os tópicos e ver no que posso ajudar!

 

http://forum.imasters.com.br/public/style_emoticons/default/clap.gif