Eventster

From Laboratório MM 5

Revision as of 06:20, 2 February 2012

Composição do Grupo

• Joana Flora - 45716

1.Introdução

Introdução Este relatório foi realizado no âmbito da Unidade Curricular de Laboratório Multimédia 5, leccionada no 1º semestre do 3º ano do curso de Novas Tecnologias da Comunicação da Universidade de Aveiro. É uma forma mais rápida e sucinta de explicar o desenvolvimento do projecto que foi proposto implementar para a época de recurso.

1.1 Objectivo do documento

Objectivo do documento O objectivo principal deste documento incide em relatar grande parte do processo de criação e desenvolvimento do projecto proposto.

A proposta era:

• Criar uma plataforma 2.0;
• utilizar as tecnologias leccionadas.

Para que fosse possível concretizar o projecto, foi implementada uma base de dados, foi ainda estruturar toda a informação a implementar (em PHP, CSS, HTML) bem como criar um layout. Posteriormente serão explicados estes processos, e serão ainda apresentadas propostas de melhoria para enriquecer um possível produto final.

1.2 Visão geral do projecto

Visão geral do projecto A Web 2.0 é conhecida pela sua dinâmica no que diz respeito ao uso da Web (internet), dinâmica essa que permite aos utilizadores a interacção entre si e participação efectiva na Web ou seja o utilizador hoje em dia não se limita apenas a ser espectador como em outros tempos, actualmente o utilizador também assume o papel de produtor / editor de conteúdos.

Foi com os olhos postos no que é a web2.0 que o meu grupo de trabalho anterior(época normal) e após terem surgido diversas ideias e todas elas incidiam em “Como é viver em Aveiro?” e as dificuldades que os estudantes e não só encontram ao chegar à cidade, e apercebemo-nos de potenciais plataformas que poderiam resultar para os jovens que passam por Aveiro. Mas após alguma reflexão, a ideia que acabou por prevalecer foi a criação de uma Agenda Cultural que permitisse aos jovens de Aveiro e não só (estudantes / não estudantes) saberem o que se andava a passar no distrito de Aveiro e quem sabe procurar o que se anda a ocorrer noutros distritos, quer a nível de workshops, actividades de diversão nocturna, convívios, festas, concursos, etc. porque muita dessa informação acaba por passar-nos ao lado e quando chega muitas vezes já não está actualizada. Para que plataforma funcionasse devidamente os utilizadores teriam de criar uma conta (comum/premmium) onde seria possível ver os eventos publicados por ele e por outros utilizadores, poderia editar/apagar os eventos que tivessem sido postados por ele, criar novos eventos, comentar os eventos, e poderia visualizar geograficamente através do Google Maps o local onde iria decorrer o evento e ainda poderia trocar mensagens “privadas” com o criador desse mesmo evento. Os utilizadores não registados apenas poderiam ver a informação publicada. Nos detalhes dos eventos seriam fornecidas informações como a localização gráfica dos eventos (através do Google maps) bem como informações de quem criou o evento, hora a que decorre o evento e os pormenores relativos a esse mesmo evento. A inserção de “Amigos” do utilizador poderia ser através de um faceboock connect, para que o utilizador pudesse partilhar com os seus amigos, eventos criados por si ou eventos em que fosse participar, ajudando assim a espalhar a informação que evento “X” irá acontecer em determinado local. Quanto ao Layout que foi pensado em grupo ira ter cores sóbrias (preto e verde) e teria um aspecto bastante sofisticado, mas quando chegou a hora de implementar o projecto individualmente, decidi que o projecto teria de ter uma imagem mais simples do que gostaria porque o tempo para trabalhar no layout e implementar o projecto era muito curto. Ainda assim como a aplicação é para jovens, acabei por fazer um banner simples mas mais colorido para dar um ar mais divertido à página. Apesar do layout não ser elaborado está funcional.

2.Base de dados desenvolvida

Esta é a imagem da base de dados:

A base de dados do projecto Eventster foi criada para desenvolver os requisitos mínimos “exigidos” para recurso, uma vez que a base de dados anteriormente implementada em grupo tinha alguns problemas. Esta base de dados foi construída no MySQL Workbench e tem 8 tabelas.

• A tabela “Eventos” é responsável por guarda toda a informação relativa eventos criados e os dados guardados são: o utilizador que criou o evento, o titulo do evento, a descrição do evento, a data e hora em que decorrerá o evento, a categoria a que pertence o evento, o local que é apresentado com url do Google Maps e o distrito onde ocorrerá o acontecimento.

• “Categorias” esta tabela foi criada para que através de um menu dropdown o utilizador possa escolher a categoria em que se insere o evento que pretende publicar.

• A tabela "Distrito" está presente porque pensei que os eventos apresentados na página de eventos podem decorrer em outros distritos do interesse dos utilizadores de Aveiro.

• Na tabela “Utilizador” é guardada toda a informação referente aos utilizadores registados. A informação guardada é: o nome, morada, localidade, distrito, nº de telefone, data de nascimento, correio electrónico, o tipo de utilizador, username, password, pergunta secreta, resposta secreta, data e hora do registo, data e hora do ultimo login. Esta tabela encontra-se interligada a grande parte das tabelas existentes na base de dados excepto à de "Categorias" e à de "Eventos" A tabela

• “ Comentários” esta tabela está encarregue de alojar toda a informação referente aos comentários efectuados e para que tal seja possível ela guarda os seguintes campos: o "id" dos comentários, os eventos que foram comentados, qual dos utilizadores efectuo o comentário e a data e hora em que foi submetido o comentário.

• A tabela “Mensagens” guarda as mensagens "privadas" trocadas entre os diferentes utilizadores registados da plataforma e abriga os seguintes campos: o "id" da mensagem, o utilizador que a enviou (emissor), o utilizador que irá receber a mensagem (receptor), guarda ainda o assunto, o corpo e a data e hora a que a mensagem foi enviada.

• “Distrito” esta tabela tal como a tabela de Categorias serve para facilitar a inserção de dados por parte do utilizador evitando erros (ortográficos, entre outros) do mesmo.

• “Tipo de utilizador” esta tabela serve para limitar o tipo de utilizadores, podendo ser utilizadores comuns (registados) ou Premium.

• A tabela de “Pergunta de segurança” serve como método de segurança, porque caso o utilizador se esqueça da password terá de contactar o admin do site para que lhe possa ser atribuída uma nova password e a pergunta secreta será uma das formas de despiste para eventuais fraudes.

3. Implementação

3.1 Descrição das principais funcionalidades da aplicação Web

A plataforma “Eventster” admite que todos os visitantes, registados ou não, possam ver os eventos submetidos pelos utilizadores registados, organizados por data e hora de submissão, ainda existe a possibilidade de ser efectuada uma pesquisa por palavra-chave para poder aceder a um determinado evento ou conjunto de eventos consoante as preferências utilizador. Caso tenha dificuldades na "navegar" na aplicação, o visitante pode consultar a página de FAQ (Frequently Asked Questions), e observar uma pequena lista das perguntas mais frequentes sobre a plataforma e os esclarecimentos. Também pode encontrar nesta pagina o contactos da equipa de desenvolvimento (neste caso eu).

É possível registar-se na própria plataforma, através do preenchimento de um simples formulário, em que basta preencher os campos obrigatórios para efectuar o registo com sucesso. Depois de ter submetido o formulário de registo, o utilizador pode/deve fazer login (que permite a entrar na aplicação Web com os seus dados) e logout (sair da aplicação Web depois de efectuado o Login). Os utilizadores registados têm ao seu dispor o seu próprio perfil com os seus dados pessoais que podem ser editados pelo utilizador sempre que este o pretenda fazer.

Quando o utilizador se encontrar Logado terá à sua disposição as seguintes funcionalidades:

• Ver/comentar/editar/apagar os eventos criados por si.
• Criar novos eventos.
• Ver/comentar eventos criados por outros utilizadores.
• Enviar/ receber/apagar mensagens ”sigilosas”.

3.2 Mapa de páginas

3.2.1 Server Behaviours utilizados

No decorrer da implementação foram usados vários Server Behaviours entre os quais:

• Insert Record – foi utilizado para inserir dados na BD, ao efectuar o registo de utilizadores, ao escrever novas mensagens e ao criar novos eventos, por exemplo

• Update Record – utilizado para actualizar os dados anteriormente inseridos ("Meu Perfil", "Editar Evento", etc)

• Dynamic Text - apresenta os dados alojados na BD

• Repeat Region – foi utilizado em algumas páginas para repetir determinados fragmentos de código / conjuntos de dados, sobretudo na página de Eventos, na de Comentários, mensagens recebidas entre outras.

Restrict Access To Page – foi utilizado para fazer a gestão de sessões porque torna o acesso restrito a determinados utilizadores. Por exemplo apenas os utilizadores registados podem publicar eventos.

3.2.2 Recordsets/Queries utilizados

3.2.3 Parâmetros passados entre páginas

Para poder passar parâmetros entre as páginas, teve de utilizar-se os métodos de GET, POST, por url, e através da Session, ou seja, para que através do id que o utilizador que tem, no momento, percebermos se a sessão está iniciada ou não.

O método GET foi utilizado para ir buscar o conteúdo de um parâmetro resolt. O método de POST foi sobretudo utilizado, no preenchimento de formulários, como o de efectuar registo.

Para conseguir perceber qual dos utilizadores fez login assim poder carregar os seus dados foi utilizado o parâmetro de Session "MM_Username", que corresponde ao username.

Sugestões de Desenvolvimento

Devido a constrangimentos de recursos, tempo e conhecimento, muitas das ideias iniciais foram abandonadas. No entanto gostaríamos de ter implementado:

1 - Integração com GoogleMaps;

2 - Sistema de localização de festas numa área a "x" distância do utilizador;

3 - Partilha de fotografias/vídeos por parte dos utilizadores;

4 - Sistema de notificação via e-mail.

Conclusões

Apesar do produto final ter ficado muito aquém das nossas expectativas, pensamos que o conceito da aplicação tem potencial para o sucesso. Temos consciência de que o mesmo não está completamente funcional, devido a problemas que nos ultrapassam e falta de meios, tempo e conhecimento, sendo que o produto final se assemelha mais a um protótipo/prova de conceito do que a um produto comercial.

Bibliografia