Faculdade de Ciências
Departamento de Informática
Desenvolvimento de Aplicação Web de Pesquisa, Gestão e
Partilha de Eventos
Luís Manuel Rochinha Oliveira
Projeto orientado pelo Prof. Doutor António Emanuel Magalhães Duarte
Pereira dos Santos
e co-orientado pelo Prof. Doutor Francisco José Moreira Couto
PROJETO
MESTRADO EM ENGENHARIA INFORMÁTICA
Especialização em Sistemas de Informação
2015
Em primeiro lugar, quero agradecer aos meus pais pelo carinho e apoio incondicional que me derem ao longo do meu percurso académico e ao longo da minha vida. Sem eles não seria possível chegar até aqui e concluir esta etapa da minha vida.
Agradeço ao meu professor e orientador Emanuel Santos, por toda a disponibilidade, dedicação e apoio ao longo deste Projeto de Mestrado.
Agradeço à minha namorada Daniela Correia o apoio, amor e carinho que me foi dado durante o meu percurso académico e em especial neste último ano de Mestrado.
Agradeço ao SAPOLabs, em particular ao Jorge Teixeira pela disponibilidade e ajuda que me foi dada.
Agradeço aos meus colegas de faculdade, em especial ao Carlos Barata, Cláudio Sa-ramagaio, João Nascimento, Jorge Miguel, Luís Santos, Mónica Abreu, Rafael Oliveira e Tiago Aparício pelo apoio e ajuda que me deram quando eu mais precisava, pelos mo-mentos de descontração e principalmente pelas suas amizades.
E agradeço a todos, que de uma forma direta ou indireta ajudaram-me na realização deste Projeto de Mestrado.
A participação e organização de eventos (tais como, eventos culturais, desportivos, mu-sicais) sempre fizeram parte da vida das pessoas, e as pessoas necessitam de uma forma simples e eficaz de pesquisar eventos. Para colmatar estas necessidades foi desenvol-vida uma aplicação web que facilita a pesquisa e a divulgação de eventos (por exemplo, eventos culturais, desportivos, musicais, etc . . . ) a realizar em Portugal. Para isso foram desenvolvidas várias funcionalidades e interfaces (para desktop e dispositivos móveis) de modo a ter uma aplicação inovadora capaz de oferecer uma boa experiência de utilizador. Nomeadamente, a visualização dos eventos no mapa associado com os filtros de pesquisa, sugestões de eventos, saber que pessoas vão aos eventos (“quem vai?"), convidar amigos para eventos, a criação de eventos, a divulgação de eventos no Facebook, seguir organi-zadores, a criação do novo conceito “Eu vou Condicional", entre outras.
O desenvolvimento desta aplicação foi composta por várias fases. Na primeira fase foi feito um caso de estudo sobre aplicações semelhantes à aplicação desenvolvida. Na segunda fase foi feita a análise de requisitos que incluiu a descrição dos serviços dispo-níveis, os requisitos funcionais, os casos de uso e os esboços. Na terceira fase foi feita a implementação da aplicação, que está divida em três camadas, nomeadamente: camada de dados, que é responsável por obter todas as informações sobre os eventos; a camada de apresentação que é responsável por apresentar uma interface ao utilizador e as respeti-vas funcionalidades da aplicação. Esta camada foi implementada utilizando a framework Backbone.js sobre a arquitetura MV*; e por último a camada de serviços que é responsá-vel por fazer a ligação entre as duas camadas referidas anteriormente, ou seja, o utilizador acede à camada de dados através de um pedido feito pela camada de apresentação. Na úl-tima fase foi feita uma avaliação/testes da aplicação, nomeadamente testes de usabilidade com utilizadores e uma equipa do Sapo especializada em User Experience. A aplicação está disponível no endereço: http://www.lasige.di.fc.ul.pt/webtools/ondequemvaiver/.
Palavras-chave: web 2.0, web services, Backbone.js, AngularJs, arquitetura MVC, Ajax, HTML5, aplicação web, redes sociais, eventos, Eu vou Condicional, Vou, usabilidade, experiência de utilizador, camada de dados, camada de apresentação, camada de serviços
Participation and organization of events (such as cultural, sports or musical events) have always been part of people’s lives, and people need a simple and effective way to search events. To address these needs, an application web that facilitates research and dissemination events (eg, cultural, sporting, musical, etc . . . ) to be held in Portugal was developed. In order to do this, many features and interfaces (desktop and mobile) were de-veloped to make this an innovative application and offer a good user experience. Namely, the visualization of the events associated with the map search filters, event suggestions, knowing which people go to events (“Who goes?”), inviting friends to events, creating events, divulgation of events on Facebook, following organizers, the creation of a new concept "I’ll Conditional", among others.
The development of this application was composed of various phases. On the first phase we have made a case study of applications similar to the developed application. On the second phase, the analysis of requirements that included the description of the ser-vices available, the functional requirements, use cases and sketches was made. The third phase focused on the implementation of the application, which was divided into three layers, namely: data layer, which is responsible for obtaining all the information about the events; the presentation layer is responsible for presenting a user interface and to the respective application functionality. This layer was implemented using the Backbone.js framework on the MV* architecture; and finally the layer of services that is responsible for making the connection between the two layers mentioned above, meaning, the ac-cess to the data layer is made through a request from the presentation layer. On the last phase, several tests were performed on the application, including usability tests with users and a Sapo team that is specialized in User Experience. The application is available at: http://www.lasige.di.fc.ul.pt/webtools/ondequemvaiver/.
Keywords: web 2.0, web services, web application, Backbone.js, AngularJs, MVC, Ajax, HTML5, social networks, events, I’ll Conditional, usability, user experience, data layer, presentation layer, service layer
Lista de Figuras xvi Lista de Tabelas xx 1 Introdução 1 1.1 Contextualização do Projeto . . . 1 1.2 Motivação . . . 1 1.3 Objetivos . . . 2 1.4 Contribuições e Metodologia . . . 3 1.5 Notação adotada . . . 3 1.6 Organização do documento . . . 3 2 Trabalho Relacionado 5 2.1 Estado da Arte . . . 5 2.1.1 Web 1.0 vs Web 2.0 . . . 5
2.1.2 Tecnologias Utilizadas na Web 2.0 . . . 7
2.1.3 Single Page Applications- SPA . . . 12
2.1.4 Responsive Web Design (RWD) vs Adaptive Web Design (AWD) . 13 2.1.5 Frameworks. . . 14
2.2 Casos de estudo . . . 23
2.2.1 Comparação de Funcionalidades . . . 29
3 Análise e especificação de requisitos 33 3.1 Análise de serviços . . . 33
3.2 Requisitos funcionais e não funcionais . . . 34
3.2.1 Requisitos funcionais . . . 34
3.2.2 Requisitos não funcionais . . . 36
3.3 Casos de uso . . . 37
3.4 Esboços da aplicação web . . . 40
3.5 Decisões técnicas face às estratégias de desenvolvimento . . . 42 ix
4.2 Alterações no planeamento do projeto . . . 47
5 Implementação da aplicação web 51 5.1 Arquitetura do Sistema . . . 51
5.2 Estrutura da Aplicação . . . 52
5.3 Processo de Renderização das Views . . . 53
5.3.1 Renderização da Página Incial . . . 53
5.3.2 Renderização da Página da Lista de Eventos . . . 54
5.4 Back-End . . . 55
5.4.1 Base de Dados . . . 55
5.4.2 Sistema de Recolha de Informação . . . 58
5.4.3 Sistema de Verificação de Imagens . . . 60
5.5 Web Services . . . 61
5.6 Models e Collections . . . 63
5.7 Views . . . 65
5.7.1 View Shell . . . 65
5.7.2 View HomeInicial . . . 66
5.7.3 ViewLista de Eventos . . . 68
5.7.4 ViewEvento . . . 71
5.7.5 ViewPerfil . . . 82
5.7.6 ViewPerfil do Organizador . . . 85
5.8 Bibliotecas para o Desenvolvimento do Front-End . . . 86
5.8.1 Bootstrap DatePicker . . . 86
5.8.2 ClockPicker . . . 86
5.8.3 Bootstrap Select . . . 87
5.8.4 SweetAlert . . . 88
5.9 Templates para o Desenvolvimento do Front-End . . . 88
6 Testes 91 6.1 Testes de Usabilidade . . . 91
6.1.1 Testes de Usabilidade Presencial . . . 93
6.1.2 Testes de Usabilidade do SapoLabs . . . 99
7 Conclusão 103 7.1 Considerações Finais . . . 103
7.2 Trabalho Futuro . . . 105
A Casos de Uso da aplicação web 107
C Esquema do Processo de Renderização da View da Página Inicial 121 D Esquema do Processo de Renderização da View da Página de Lista de Eventos123
E Tabela de web services da aplicação web 125
F Models e Collections da aplicação web 131
G Páginas da aplicação web 135
H Questionário Teste de Usabilidade 139
I Lista de Problemas identificado pelo SapoLabs 147
Abreviaturas 152
Bibliografia 157
Índice 158
2.1 Tag<META> que exemplifica uma atualização de uma página . . . 7
2.2 Método getElementById . . . 8
2.3 Método innerHTML . . . 9
2.4 Propriedade parentNode . . . 9
2.5 Propriedade childNodes . . . 9
2.6 Representação do efeito transição usando regras CSS . . . 10
2.7 Diferença entre aplicações que usam e não usam Ajax . . . 12
2.8 Representação da relação entre Model, View, Controller . . . 15
2.9 Exemplo de um Template de uma View . . . 16
2.10 Interação entre os models e as views. . . 17
2.11 Representação de Collections . . . 17
2.12 Representação da Renderização de Views . . . 18
2.13 Representação do Routing . . . 18
2.14 Expressoes . . . 19
2.15 Diretiva ng-repeat . . . 19
2.16 Diretiva ng-controller . . . 20
2.17 Representação de um module . . . 20
2.18 Representação de duas routes . . . 21
2.19 Binding Bidirecional . . . 22
2.20 Disposição de três colunas num desktop . . . 23
2.21 Disposição de três colunas num dispositivo móvel . . . 23
2.22 Página que representa os resultados de uma pesquisa pela localidade Viseu 24 2.23 Página que representa os resultados de uma pesquisa pela keyword Jorje Jesus . . . 26
2.24 Página inicial do website EntradaLivre . . . 27
2.25 Página de um evento do website EntradaLivre . . . 28
2.26 Página da lista de anúncios . . . 29
3.1 Pedido SOAP para obter eventos em Lisboa e Porto . . . 34
3.2 Pedido REST para obter a lista de distritos . . . 34
3.3 Diagrama de Casos de Uso . . . 38
3.4 Esboço da página lista de eventos da aplicação web/desktop . . . 40 xiii
3.7 Esboço da página Evento da aplicação mobile . . . 42
4.1 Designda página evento antes da mudança . . . 48
4.2 Designda página evento depois da mudança . . . 48
4.3 Designda página meus eventos antes da mudança . . . 49
4.4 Designda página meus eventos antes da mudança . . . 49
5.1 Arquitetura do Sistema . . . 51
5.2 Organização do código da aplicação . . . 52
5.3 Ficheiro index.html . . . 53
5.4 Renderização da View shell.js . . . 53
5.5 Renderização da View da Página Inicial, após detetar o respetivo Router associado . . . 54
5.6 Templateshell.html associado à View shell.js . . . 54
5.7 Renderização da View Lista de Eventos, após detetar o respetivo Router associado . . . 55
5.8 Modelo Entidade Associação retirado da ferramenta MySQL Workbench 56 5.9 Variáveis para fazer o pedido ao serviço Culture . . . 59
5.10 Pedido através do cURL . . . 60
5.11 Renderização das imagens de eventos criados por organizadores . . . 60
5.12 Pedido HTTP GET . . . 62
5.13 Pedido HTTP GET para obter os dados de um utilizador . . . 62
5.14 Resposta do pedido HTTP GET em formato JSON . . . 62
5.15 Pedido HTTP GET para obter os eventos favoritos de um utilizador . . . 63
5.16 Resposta do pedido HTTP GET em formato JSON . . . 63
5.17 Model responsável por obter os dados de um utilziador . . . 64
5.18 Inicialização do Model “UserModel” para obter os detalhes de um utilizador 64 5.19 Model responsável por adicionar um interesse na base de dados . . . 65
5.20 Inicialização do Model “AddInteresses” para adicionar um interesse de um utilizador . . . 65
5.21 Botão para fazer login no Facebook . . . 66
5.22 Barra de navegação depois do efetuado o login . . . 66
5.23 Barra de navegação depois do efetuado o login . . . 66
5.24 Serviço Autocomplete . . . 67
5.25 Página com a lista de eventos resultante de uma pesquisa realizada . . . . 68
5.26 Interrogação SQL para obter eventos que tenham uma distância menor que cinco quilómetros, dado um local . . . 69
5.27 Marcadores no mesmo local, representados em círculo . . . 70 xiv
5.30 Direções obtidas para ir ao evento a partir da localização corrente . . . 72
5.31 Vista panorâmica do local do evento . . . 73
5.32 Estado dos botões antes de serem selecionados . . . 74
5.33 Select Button que indica a opção pela qual o utilizado vai ao evento . . . . 74
5.34 Modal com a lista de datas e horas disponíveis . . . 75
5.35 Modal com a lista de amgios e de datas e horas disponíveis . . . 76
5.36 Select Button com a opção Vou e Vou Se . . . 76
5.37 Pseudocódigo . . . 77
5.38 Botões Ver Datas e Ver Amigos . . . 78
5.39 Modal com as datas que o utilizador vai ao evento . . . 78
5.40 Modal com a lista de amigos que vão ou ainda não vão ao evento . . . 79
5.41 Link para adicionar ao Google Calendar . . . 79
5.42 Página do link para adicionar ao Google Calendar . . . 80
5.43 Recomendação de eventos . . . 81
5.44 Botão seguir organizador . . . 82
5.45 Página de perfil do utilizador . . . 83
5.46 Representação do calendário da biblioteca DatePicker . . . 86
5.47 Representação do relógio da biblioteca ClockPicker . . . 87
5.48 Select da framework Bootstrap . . . 87
5.49 Select da biblioteca Bootstrap Select . . . 87
5.50 JavaScript Alert . . . 88
5.51 Alert da biblioteca SweetAlert . . . 88
5.52 Página Inicial da Aplicação Web . . . 89
6.1 Percentagem de conclusão de cada tarefa . . . 96
6.2 Evento com imagem de um organizador . . . 96
6.3 Overde uma imagem de um evento na lista de eventos . . . 97
6.4 Botões para visualizar as datas, amigos e adicionar ao Google Calendar . 97 6.5 Percentagem de melhoramento ou não melhoramento de cada tarefa . . . 98
6.6 Escala de dificuldade de cada tarefa . . . 99
B.1 Esboço da página Filtros de Pesquisa da aplicação web/desktop . . . 117
B.2 Esboço da página lista de eventos da aplicação mobile . . . 117
B.3 Esboço da página Criar Evento da aplicação web/desktop . . . 118
B.4 Esboço 1 da página Criar Evento da aplicação mobile . . . 118
B.5 Esboço 2 da página Criar Evento da aplicação mobile . . . 118
B.6 Esboço 3 da página Criar Evento da aplicação mobile . . . 119
B.7 Esboço da página Perfil do Utilizador da aplicação web/desktop . . . 119 xv
C.1 Renderização da página inicial da aplicação web . . . 122
D.1 Renderização da página inicial da aplicação web . . . 124
G.1 Página da lista dos eventos . . . 135
G.2 Página do evento . . . 135
G.3 Página do perfil do utilizador . . . 136
G.4 Página criar evento . . . 136
G.5 Página responsável por gerir eventos . . . 137
G.6 Página do perfil do organizador . . . 137
H.1 Cabeçalho do questionário . . . 139 H.2 Tarefas 1 e 2 . . . 140 H.3 Tarefas 3, 4 e 5 . . . 141 H.4 Tarefas 6, 7 e 8 . . . 142 H.5 Tarefas 9, 10 e 11 . . . 143 H.6 Tarefas 12, 13 e 14 . . . 144 H.7 Tarefas 15, 16 e 17 . . . 145 xvi
2.1 Comparação entre a Web 1.0 e a Web 2.0 . . . 6
2.2 Comparação de funcionalidades . . . 31
3.1 Requisitos Funcionais . . . 36
3.2 Versões dos browsers que suportam a aplicação . . . 37
3.3 Caso de uso pesquisar evento . . . 39
3.4 Caso de uso adicionar evento à wishlist . . . 39
3.5 Caso de uso criar evento . . . 40
5.1 Web servicesque obtém os dados do utilizador . . . 62
5.2 Web servicesque obtém os eventos favoritos do utilizador . . . 63
6.1 Tarefas do questionário de usabilidade . . . 94
6.2 Tabela do que é esperado por cada tarefa . . . 95
6.3 Número de vezes que cada heurística foi violada . . . 100
A.1 Caso de uso login com o Facebook . . . 107
A.2 Caso de uso visualizar lista de eventos . . . 107
A.3 Caso de uso visualizar evento . . . 108
A.4 Caso de uso adicionar evento ao Google Calendar . . . 108
A.5 Caso de uso visualizar wishlist . . . 108
A.6 Caso de uso comentar/classificar evento . . . 109
A.7 Caso de uso vou . . . 109
A.8 Caso de uso vou se . . . 110
A.9 Caso de uso não vou . . . 110
A.10 Caso de uso partilhar eventos . . . 111
A.11 Caso de uso visualizar eventos atuais, passados e futuros . . . 111
A.12 Caso de uso visualizar notificações . . . 112
A.13 Caso de uso seguir organizador . . . 112
A.14 Caso de uso não seguir organizador . . . 112
A.15 Caso de uso visualizar datas . . . 113
A.16 Casos de uso visualizar amigos . . . 113
A.17 Caso de uso atualizar perfil do utilizador . . . 114 xix
E.1 Tabela de web services . . . 129 F.1 Modelse Collections da aplicação web . . . 134 I.1 Lista de problemas com as heurísticas violadas . . . 150
Introdução
Neste capítulo é descrita a contextualização e a motivação para a realização deste Projeto de Mestrado, bem como os objectivos a atingir. É ainda apresentada a notação adotada para a escrita do documento, a sua organização, os objetivos a contretizar e as contribui-ções deste Projeto de Mestrado.
1.1
Contextualização do Projeto
A participação e organização de eventos (por exemplo, eventos culturais, desportivos, mu-sicais, cinema, etc . . . ) sempre fizeram parte da vida das pessoas, e estas esperam uma forma simples e eficaz de pesquisar e encontrar um evento em que queiram participar. As tecnologias Web 2.0 tornaram possível a criação de aplicações que facilitam a orga-nização/criação, procura e partilha de eventos de vários tipos de géneros, nomeadamente através das redes sociais. Assim, a Web 2.0 [23] tem como um dos objetivos fornecer um software como um serviço continuamente atualizado, que é melhorado à medida que as pessoas o usam. Um “bom” exemplo deste tipo de software é a Wikipédia1, que tem como objetivo fornecer um conteúdo reutilizável livre, objetivo e verificável, de modo a que todas as pessoas possam editar e melhorar o conteúdo. Para além disso, a Web 2.0 permite a qualquer utilizador partilhar os seus próprios dados e serviços com outros utili-zadores, criando assim um efeito de “arquitetura de participação”. Por isso, as aplicações webdesempenham um papel fundamental na forma como se relacionam com as pessoas.
1.2
Motivação
Este projeto surge na sequência do Mundial de Futebol - Brasil 2014, em que foi criado o projeto “Onde Há Bola?”2, cujo objetivo foi a criação de uma aplicação web capaz de indicar os locais onde se pode assistir aos jogos do Mundial, e saber o número de pessoas
1https://pt.wikipedia.org 2http://ondehabola.labs.sapo.pt/
que estão apoiar cada uma das equipas em cada um desses locais. Nesta aplicação, o utilizador pode escolher um local perto de si para apoiar a sua equipa favorita num ambi-ente mais favorável, ao mesmo tempo que pode partilhar à comunidade a sua intenção de assistir ao jogo e a equipa que irá apoiar.
Após a conclusão do projeto do projeto “Onde Há Bola?”, sentiu-se a necessidade de investigar se haveriam aplicações web que oferecessem funcionalidades básicas (por exemplo, pesquisar, partilhar, organizar eventos etc. . . ) relacionadas com a criação, ges-tão e divulgação de todo o género de eventos (por exemplo, eventos culturais, desportivos, musicais, cinema, etc . . . ) para além dos desportivos. Como resultado desta investigação, verificou-se que as aplicações relacionadas com eventos apresentavam algumas falhas ao nível da usabilidade, principalmente quando acedidas nos dispositivos móveis, mas tam-bém nas principais funcionalidades que este tipo de aplicações web deveriam ter, nome-adamente: na pesquisa de eventos numa região; na informação disponibilizada sobre os eventos em Portugal; na criação e partilha de eventos nas redes sociais; na possibilidade seguir organizadores de eventos e receber notificações dos mesmos; e na recomendação de eventos. Com base no resultado desta análise/investigação, este projeto foi lançado para criar uma aplicação que fosse capaz de colmatar estas falhas apresentadas pelas apli-cações.
1.3
Objetivos
São três os objetivos principais para a realização deste Projeto de Mestrado. O primeiro objetivo é desenvolver um sistema automático de recolha de informações sobre eventos com a colaboração do SAPOLabs, nomeadamente através da disponibilização dos respe-tivos serviços.
O segundo objetivo é desenvolver um conjunto de web services necessários para fazer a ligação entre a camada de apresentação e a camada de dados.
O terceiro objetivo é desenvolver uma aplicação web para pesquisa, partilha e criação de eventos a realizar em Portugal. Deste modo, a aplicação deverá cumprir com todos os requisitos propostos, e apresentar uma boa usabilidade de forma a que os utilizado-res possam usufruir das funcionalidades da aplicação web em qualquer dispositivo, tanto desktopcomo mobile.
O primeiro e o terceiro objetivo correspondem à camada de dados e de apresentação respetivamente. Estes dois objetivos comunicam entre si através de web services, ou seja, camada de serviços.
Ao longo do projeto serão realizados testes de usabilidade de forma a obter feedback por parte dos utilizadores, permitindo fazer refinamentos no projeto, melhorando a sua usabilidade e as suas funcionalidades.
1.4
Contribuições e Metodologia
As contribuições para este Projeto de Mestrado são:
1. Implementação de um sistema automático de recolha de informações sobre eventos; 2. Implementação de um conjunto de web services que permite obter informações
sobre os dados guardados na base de dados;
3. Implementação de uma aplicação web responsive de pesquisa, gestão e partilha de eventos com as respetivas funcionalidades;
Este Projeto de Mestrado serviu também para aplicar conhecimentos sobre a expe-riência do utilizador, bem como os conhecimentos sobre a web 2.0, nomeadamente os design principles, especialmente no que respeita à participação ativa dos utilizadores para criação e manutenção do conteúdo – Crowd Computing.
1.5
Notação adotada
A notação adotada para este documento foi a língua portuguesa com o novo acordo orto-gráfico. Expressões que são citadas noutro idioma, estarão em itálico.
Para a bibliografia e citações usou-se o estilo descrito na Norma ISO 690 com o uso de referência numérica.
1.6
Organização do documento
Este documento está organizado da seguinte forma:
• Capítulo 2 (Trabalho Relacionado) apresenta o estado da arte no desenvolvimento de aplicações web, e casos de estudo sobre aplicações semelhantes ao projeto de-senvolvido.
• Capítulo 3 (Análise e Especificação de Requisitos) é apresentada a análise de serviços a utilizar para o projeto, os requisitos funcionais e não funcionais, os dife-rentes casos de uso do projeto e os esboços. São também definidas as estratégias e as suas justificações para o desenvolvimento do projeto.
• Capítulo 4 (Plano de Trabalho) apresenta a calendarização do projeto, e as expli-cações para as mudanças feitas em relação ao plano de trabalho inicial, assinalando os motivos que levaram ao atraso da conclusão do projeto.
• Capítulo 5 (Implementação da Aplicação Web) é descrito os diferentes estados no desenvolvimento da aplicação até à sua conclusão.
• Capítulo 6 (Testes) são descritos os testes de usabilidade realizados para obter resultados relativamente ao uso da aplicação web.
• Capítulo 7 (Conclusão) são apresentadas as conclusões finais do projeto, e o tra-balho futuro.
Trabalho Relacionado
Neste capítulo é apresentado o estado da arte no desenvolvimento de aplicações web e ainda os casos de estudo de outras aplicações web.
2.1
Estado da Arte
Nesta secção são apresentadas as diferenças entre a Web 1.0 e a Web 2.0 bem como as tecnologias que a Web 2.0 oferece no desenvolvimento de aplicações. São também apsentadas duas frameworks, Backbone.js e AngularJs, descrevendo os seus objetivos e re-alçando as suas diferenças. A seguir é feita uma descrição da framework Bootstrap. A subsecção seguinte foi escrita com base nas referências: [13], [26], [1] e [28].
2.1.1
Web 1.0 vs Web 2.0
A criação dos primeiros websites da World Wide Web, conhecidos hoje como Web 1.0, estava restrito a um conjunto de pessoas relacionadas com a criação de websites. O utili-zador apenas podia aceder a páginas estáticas, cujo o conteúdo apresentado ao utiliutili-zador era pouco interativo e era apenas um espaço para leitura de informação. Os serviços GeoCities1e Hotmail2, são dois exemplos que definem o período da Web 1.0.
A Web 1.0 apresenta várias funcionalidades e características no seu web design, no-meadamente: o uso de elementos do HTML 3.2, tais como frames e tabelas para alinhar os elementos numa página; a utilização de Online GuestsBooks, sistema de registos que permite aos utilizadores de um website deixar um comentário público; envio de emails através de formulários HTML, em que o utilizador preenchia um formulário, e este era enviado pelo cliente de email do servidor com todos os detalhes que o utilizador tinha in-serido. Tipicamente as páginas eram construídas usando Server Side Includes3 ou CGI4,
1serviço de hospedagens de sites. 2serviço de email baseado na Web.
3é uma linguagem de scripting interpretado do lado do servidor usado quase exclusivamente para a Web. 4tecnologia que permite gerar páginas dinâmicas, permitindo a um navegador passar parâmetros para um programa alojado num servidor Web
em que o conteúdo era obtido através do sistema de arquivos do servidor, em vez do uso de base de dados relacional.
A evolução na web 1.0, trouxe o que hoje é chamado de web 2.0. Essa mudança está relacionada com o conteúdo que passa também a ser gerado pelo utilizador, e também na forma como os utilizadores interagem e colaboram uns com os outros através de ferra-mentas de social media. Permite também aos developers criar facilmente e rapidamente aplicações web baseadas em dados, serviços e informações provenientes da internet. As-sim, a Web 2.0 é uma coleção de tecnologias, estratégias de negócio e de tendências sociais. Algumas das principais características da Web 2.0 são:
1. Social Tagging - Classificação livre de informação, ou seja, permite aos utilizadores classificar coletivamente e encontrar informação;
2. Experiência do utilizador rica - conteúdo dinâmico e responsivo usando a tecno-logia Ajax [28];
3. Utilizador como contribuidor - a informação flui de duas maneiras entre o criador do website e o utilizador do website, por meio de avaliação, revisão e comentários, como por exemplo Amazon5;
4. Participação do utilizador ou Crowd Sourcing - os utilizadores podem adicionar conteúdo num website para que outros possam ver;
5. Confiança - os conteúdos são disponibilizados para serem partilhados, reutilizados e editados, por exemplo a Wikipédia6.
A tabela 2.1, compara as características principais entre a Web 1.0 e a Web 2.0, onde são visualizadas as diferenças entre ambas.
Web 1.0 Web 2.0
A maior parte somente leitura
web Leitura e escrita web
Focada em empresas Focada em comunidades
Homepages/websitespara
compras Blogs
Dono do próprio conteúdo Partilha do conteúdo
HTML, portlas XML, RSS
Netscape Google
Formulários web Aplicações web
Webera um portal de informação
Webé uma plataforma para os utilizadores criarem
conteúdos Tabela 2.1: Comparação entre a Web 1.0 e a Web 2.0
5http://www.amazon.com/ 6https://pt.wikipedia.org/
2.1.2
Tecnologias Utilizadas na Web 2.0
As linguagens de marcação (por exemplo, HTML, XML, etc. . . ), apresentam algumas limitações, nomeadamente: não permitem a ligação com uma base de dados; e não permi-tem interação com o utilizador, sem o uso de outras linguagens (por exemplo, JavaScript). Estas fornecem instruções de formatação para a renderização estática do conteúdo. Para obter a apresentação de uma página web, os servidores HTTP transmitem respostas que contêm documentos HTML, em que os browsers fazem a renderização dos documentos obtidos nessas respostas. O principal problema é que essa apresentação é estática, ou seja, o HTML não tem um mecanismo que suporte a modificação da página depois desta ter sido renderizada. A página renderizada matém-se inalterada até ao próximo pedido. Mesmo uma simples operação, como por exemplo a validação de um form, requer um processamento no lado do servidor, o que significa que é necessário uma nova conexão ao servidor.
O objetivo principal desta secção é a apresentação da interatividade dinâmica nas pá-ginas web, começando por apresentar os primeiros métodos usados para produzir essa interatividade, passando para o JavaScript, CSS, HTML5 e AJAX. As subsecções seguin-tes foram escritas com base nos seguinseguin-tes artigos: [28], [25], [16].
Método “Meta-Refresh”
No início da web houve algumas aproximações para mudar o conteúdo da página depois desta ter sido carregada. O método “meta-refresh” usa a tag <META> do HTML, para simular a presença de um cabeçalho HTTP Refresh, que após um período de tempo espe-cífico, faz o carregamento da página a partir do URL corrente (efetivamente para atualizar conteúdo da página) ou redirecionar o browser para uma nova página. Este processo faz com que o conteúdo de toda a página seja recarregado, mesmo para pequenas alterações.
Figura 2.1: Tag <META> que exemplifica uma atualização de uma página
A diretiva representada na figura 2.1, quando inserida dentro tag <HEAD> num docu-mento HTML, redireciona o browser para um novo específico URL após cinco segundos a página ter sido carregada. Esta solução é uma técnica grosseira para a apresentação de conteúdo dinâmico, mas eficaz no início da web.
JavaScript
O método “meta-refresh” apresentado anteriormente não é um substituto para um com-portamento programável. Por isso é necessário ter uma funcionalidade verdadeiramente programática no browser. Ao longo do tempo, a especificação do HTML evoluiu para
suportar event handlers, isto é, código que é executado quando um evento ocorre no browser (por exemplo, quando um utilizador clica num link, quando o cursor do rato passa por cima de um elemento, ou quando são inserido dados num form). Implementar estes events handlers requer uma linguagem de programação que seja capaz de ser execu-tada no browser e na interface com o DOM (Document Object Model). Com base nestes princípios surgiu o JavaScript, uma linguagem de programação para a web executada no lado do cliente. Esta linguagem permite controlar o HTML (e mais tarde o CSS) para manipular comportamentos numa página.
Existem duas aproximações para usar JavaScript como mecanismo para manipular o conteúdo do documento. A primeira consiste no uso de declarações document.write. Esta função, como o próprio nome indica, permite escrever conteúdo dentro de um documento. Se esta declaração for invocada enquanto a página está a ser carregada, então o novo con-teúdo é inserido num determinado ponto do documento onde a declaração foi invocada. Caso, esta tenha sido invocada depois de a página ter sido carregada, o conteúdo existente é limpo e é carregada novamente a página.
A segunda aproximação usa métodos do JavaScript para manipular o DOM. Estes métodos podem ser empregues depois do browser carregar a página sem ser necessário que todo o documento seja limpo. O DOM é organizado como uma árvore, à semelhança do que acontece no XML. É uma representação hierárquica de uma página HTML, em que cada tag do HTML é equivalente a um nó num documento XML. Contudo, nem todos os documentos HTML estão formatados de acordo com as especificações do XML. Os browserstentam produzir uma árvore DOM a partir desses documentos que não estão bem formatados, e as árvores que são produzidas pelos diferentes browsers são inconsistentes. Este problema é resolvido com o HTML5, em que há mapeamentos bem definidos a partir de documentos HTML não formatados para estruturas DOM adequadas.
Com o JavaScipt podemos então manipular os elementos HTML que se encontram no DOM. Cada elemento no HTML pode estar identificado por um “id” único. O método getElementByIdpermite encontrar um elemento HTML no DOM, como mostra a figura 2.2.
Figura 2.2: Método getElementById
Após encontrar um elemento através do método representado na figura 2.2, podemos mudar o seu conteúdo com o uso do método innerHTML. A figura 2.3 representa a mu-dança do conteúdo de um elemento por “new text”.
Figura 2.3: Método innerHTML
Cada nó no HTML DOM (excepto a raiz do documento) tem a propriedade parent-Node, como mostra a figura 2.4.
Figura 2.4: Propriedade parentNode
A propriedade childNodes é um array que contém todos os nós filhos do nó pai. Neste exemplo, figura 2.5, a propriedade parent.childNodes refere-se ao nó corrente e a todos os seus filhos que dele descendem.
Figura 2.5: Propriedade childNodes
Para além destes exemplos, existem inúmeros métodos que o JavaScript fornece para a manipulação dos elementos HTML no DOM.
CSS
Folhas de estilo em cascata, do inglês Cascading Style Sheets (CSS), é um mecanismo para controlar estilos (por exemplo, cores, fontes, etc. . . ) no HTML. Uma folha de estilo é feita de regras que determinam como os elementos de uma página devem ser renderizados. As regras podem ser aplicadas a um elemento individual com um atributo “id” único, a um grupo de elementos que partilham o atributo “class”, ou elementos representados pela mesma tag HTML. A palavra "cascata” é usada porque várias regras podem ser aplicadas aos mesmos conjuntos e subconjuntos de elementos de uma página. O CSS é também responsável pela manipulação de elementos HTML no DOM. A figura 2.6 representa o efeito de transição de um elemento “div”, quando o cursor do rato paira sobre esse mesmo elemento.
Figura 2.6: Representação do efeito transição usando regras CSS
HTML5
O HTML5 é uma linguagem de marcação utilizada para estruturar e representar conteúdo para a World Wide Web. É a versão mais recente da linguagem HTML e com ela trouxe no-vas novidades que ajudam no desenvolvimento de aplicações web. O W3C desenvolveu o HTML5 com vários objetivos em mente: substituir plug-ins de propriedades multimédia com padrões abertos, permitir que as aplicações web tenham um comportamento pare-cido com as aplicações nativas, adicionando funcionalidades para serviços baseados em localização, e fazer alterações na sintaxe que separa o conteúdo da apresentação.
As funcionalidades mais abordadas no HTML5 é o suporte nativo dos browsers para a reprodução de áudio e vídeo. Isto veio permitir aos designers inserir as tags <video> e <audio> nas páginas HTML. Essas contêm a informação no qual o browser pode usar para interpretar e reproduzir o conteúdo de multimédia.
Outra funcionalidade importante no HTML5 é a possibilidade de desenvolver aplica-ções web que têm um comportamento parecido com as aplicaaplica-ções locais. Funcionalidades como o drag and drop e armazenamento local, dá a liberdade ao utilizador de poder in-teragir com o seu desktop. O HTML5 suporta no lado do cliente base de dados SQL e offline chaching, sendo particularmente importante para os utilizadores que usam dis-positivos móveis, uma vez que a maioria das conexões são limitadas. Um exemplo deste conceito é o uso do calendário, em que o utilizador é capaz de fazer o download dos dados do calendário para o seu dispositivo, fazer os ajustes de acordo com as suas necessidades e mais tarde fazer upload dessas modificações quando existisse uma conexão disponível. As aplicações podem armazenar gráficos e código localmente no dispositivo, garantindo tempos de carga rápidos e o mínimo de tráfego de rede.
O elemento Canvas é outra das funcionalidades do HTML5. Este elemento permite aos developers fazer a renderização dinâmica de gráficos, imagens, áudio e vídeo dentro de um espaço pré-definido na página web. Estes elementos podem ser programados em
JavaScript e assim os utilizadores são capazes de interagir com esses elementos através do rato e do teclado.
O HTML5 apresenta também o serviço de Geolocalização (do inglês Geolocation). Esta funcionalidade incluída nos browsers recentes, permite criar aplicações que neces-sitam da localização atual do utilizador. Dependendo da finalidade das aplicações, esta funcionalidade pode oferecer ao utilizador a possibilidade de obter direções para um de-terminado local a partir da sua posição corrente, como também ver o que o rodeia medi-ante a sua localização. Estas funcionalidades vieram melhorar a experiência do utilizador e o design das aplicações web.
Tecnologia Ajax
À medida que a Internet evoluiu, as aplicações web caracterizadas por interfaces de uti-lizador responsivas e capacidades interativas tornaram-se cada vez mais populares. Estas características representam um forma de desenvolver aplicações mais facilmente e mais funcionais, melhorando a experiência do utilizador.
Contudo as aplicações web apresentam problemas de performance lenta e de intera-tividade limitada, quando comparadas com aplicações nativas de desktop. Para resolver estes problemas as aplicações web usam a tecnologia Ajax (Asynchronous Javascript). Esta tecnologia permite adicionar ou receber dados numa área selecionada da página web sem que se faça o reload da página toda. Isto acontece por exemplo no Google Maps7, em que se um utilizador mantiver pressionado o botão esquerdo do rato sobre o mapa e mover o cursor do mesmo, parte do mapa que estava escondido é mostrado instantanea-mente sem fazer o reload da página toda. Caso não usasse essa tecnologia, os utilizadores teriam de esperar algum tempo para que a página fosse recarregada novamente, mesmo para pequenas alterações. O Ajax usa várias componentes tecnológicas web para obter uma boa experiência do utilizador. Essas componentes são: DHTML (que engloba ele-mentos HTML, CSS e JavaScript), XML e JSON.
A figura 2.7 ilustra a diferença entre uma aplicação que usa Ajax e outra em que não usa.
Figura 2.7: Diferença entre aplicações que usam e não usam Ajax
Na figura 2.7 (a) corresponde a uma aplicação web tradicional, em que representa a forma como os pedidos são executados. O utilizador faz um pedido HTTP ao servidor web, em que este processa o pedido e retorna uma página HTML ao cliente. Os pedidos adicionais são colocados em espera até que o sistema atualize a página. Na figura 2.7 (b) corresponde a uma aplicação web que usa a tecnologia Ajax. Estas aplicações criam um motor baseado em JavaScript que é executado no browser. O motor intercepta inputs do utilizador, exibe o material pedido, e lida com muitas interações no lado do cliente. Se o motor necessitar de mais dados, este solicita material a partir do servidor em background, permitindo ao utilizador continuar a interagir com a aplicação.
2.1.3
Single Page Applications - SPA
Uma SPA [31] é uma aplicação web que é apresentada numa única página web com o objetivo de oferecer uma melhor experiência de utilizador semelhante com uma aplicação de desktop. Nas SPA todo o código necessário, é obtido apenas com um carregamento da página, e os recursos posteriormente necessários são dinamicamente carregados e adicio-nados à página. Tipicamente, este carregamento dinâmico é realizado quando o utilizador interage com a página ou quando é necessário manter o conteúdo atualizado, por exemplo jogos, notificações de email, etc. . . Num website típico uma página é dividida em várias secções: header, footer e uma área principal com o conteúdo. Quando um utilizador clica
num link e muda de página apenas o conteúdo vai ser modificado, apesar de carregar no-vamente a página toda. As SPA por sua vez, incorporam todo o conteúdo das múltiplas páginas numa só única página, mantendo apenas um conteúdo visível de cada vez. As-sim, cada vez que um utilizador clica num link, em vez de ter de solicitar uma nova página inteira a partir do servidor, a SPA esconde o conteúdo atual e exibe o novo conteúdo no lugar do conteúdo anterior.
Outras SPA utilizam Ajax para atualizar certos conteúdos da página, permitindo que o utilizador continue a realizar outras operações sem ter que esperar pelo carregamento solicitado.
2.1.4
Responsive Web Design (RWD) vs Adaptive Web Design (AWD)
Com o aumento do uso dos dispositivos móveis por parte dos utilizadores, houve a neces-sidade de adaptar os websites aos vários tamanhos de ecrãs. Um website em que os seus elementos se adaptam aos diferentes tamanhos de ecrãs é designado de responsive. Exis-tem dois métodos que os developers podem utilizar para que um website seja responsive, nomeadamente: Responsive Web Design (RWD) e Adaptive Web Design (AWD).
Esta secção foi escrita com base nos seguintes artigos: [19] e [14]. Responsive Web Design (RWD)
Responsive Web Design (RWD)é uma abordagem para o web design de sites que oferece uma experiência de visualização e navegação optimizada com o mínimo de redimensio-namento e scrolling, que é aplicada a vários dispositivos. Um site RWD muda os seus elementos na página consoante o tamanho de ecrã, utilizando apenas um único layout. Essa mudança é feita usando grids fluidas e proporcionais, imagens flexíveis, e CSS3 media queries.
Um site RWD usa as três seguintes regras:
1. A grid fluida requer que os elementos estejam em unidades relativas, como percen-tagens, em vez de unidades absolutas como pixels ou pontos;
2. As imagens flexíveis requerem que as suas unidades sejam também relativas, para evitar que estas saiam fora dos seus elementos HTML.
3. A utilização de media queries permite que a página use diferentes estilos de CSS de acordo com as características do dispositivo, tipicamente esses estilos são mudados consoante a sua largura.
Adaptive Web Design (AWD)
Ao contrário do RWD, o AWD apresenta vários layouts de acordo com o tamanho do dispositivo. O layout utilizado depende do tamanho do ecrã detetado. Tipicamente, as
aplicações web que utilizam o método AWD possuem layouts específicos para telemóveis, tabletse desktops. Ao detectar-se o tipo de dispositivo utilizado é selecionado o layout responsável por esse mesmo tipo de dispositivo.
Comparação entre RWD e AWD
Apesar de ambos os métodos terem como objetivo de melhorar a interação do utilizador com qualquer tipo de dispositivo, ambos apresentam vantagens e desvantagens compara-tivamente.
1. RWD é mais difícil de implementar - necessita de um esforço maior por parte do developeruma vez que o método RWD apenas tem um layout com todo o CSS e or-ganização do website, tendo que fazer por exemplo, várias media queries de forma a assegurar que funciona corretamente em qualquer tamanho possível. Geralmente é mais fácil desenvolver alguns layouts específicos para o website do que desenvolver apenas um layout que funcione em qualquer tamanho de ecrã.
2. AWD é menos flexível - No design Adaptive existem vários layouts para alguns tamanhos de ecrã. Caso um novo dispositivo com um novo tamanho de ecrã apa-reça, e não exista um layout para esse tamanho, então será necessário fazer um novo layout. Ao contrário, o design Responsive é mais flexível e por isso caso haja um novo dispositivo com um novo tamanho de ecrã, o website irá adaptar-se a esse novo tamanho, tendo que provavelmente apenas modificar o CSS do layout.
3. Sites RWD carregam mais rapidamente - Os websites Adaptive necessitam de carregar todos os layouts que se encontram no servidor, enquanto que os websites Responsive apenas necessitam de carregar um layout. Logo, o tempo de carrega-mento de todos os layouts necessários para um website que usa o método Adaptive é tipicamente maior em relação aos websites Responsive. Esta situação poderá nem sempre ocorrer, dependendo do número de páginas de cada método. Por exem-plo, se existir um website RWD com cem páginas em comparação com um website Adaptivecom dez páginas, o carregamento de apenas um layout será provavelmente maior do que o carregamento de vários layouts.
2.1.5
Frameworks
Para o desenvolvimento de Single Page Applications existem várias frameworks, tais como, Backbone.js, AngularJs, Ember.js, Knockout.js. Apenas são abordadas as fra-meworks Backbone.js e AngularJs, pois são atualmente as frameworks mais populares. Nesta secção, é feita uma breve introdução sobre a arquitetura MVC, e a descrição das duas frameworks. Esta secção foi escrita com base nos seguintes artigos: [4], [24], [3], [9], [6], [27], [32], [7] e [18].
Arquitetura MVC
Model - View - Controller(MVC) é um padrão de arquitetura de software que faz a se-paração da camada de dados (Model) com a camada de apresentação (View), utilizando um componente (Controller) para fazer a ligação entre estas duas camadas, como mostra a figura 2.8.
Figura 2.8: Representação da relação entre Model, View, Controller
O Model contém a lógica do negócio e funções que manipulam os dados da aplicação. A View é responsável pela apresentação do aspeto da aplicação de acordo com o estado corrente do Model. Por último, o Controller aceita e intercepta os pedidos do utilizador para atualizar a apresentação da View ou para atualizar o estado do Model.
O uso da arquitetura MVC no desenvolvimento de aplicações, apresenta um conjunto de vantagens, nomeadamente:
• Reaproveitamento de código e regras; • Facilidade de manutenção;
• Camada de persistência independente;
• Facilidade na implementação de camadas de segurança; • Facilidade na atualização da interface da aplicação.
Esta arquitetura é também utilizada para o desenvolvimento de aplicações web, onde a página HTML representa a View, e o código que gera os dados dinâmicos para o HTML é o Controller. O Model tipicamente é responsável por representar os dados que se en-contram na base de dados. A grande das maiorias das frameworks desenvolvidas para criar SPA, basearam-se na arquitetura MVC. Contudo, existem frameworks que seguem a arquitetura MV*, uma vez que não apresentam um Controlller. Isto porque a lógica que
opera a aplicação está presente na View. Para além disto, este tipo de arquitetura apre-senta outros componentes, como por exemplo Collections e Routers, como é o caso da frameworkBackbone.js.
Backbone.js
Backbone.js é uma framework para desenvolver aplicações web dinâmicas sobre a ar-quitetura MV*. Esta framework permite representar dados do servidor como Models, garantindo suporte à validação, exclusão e gravação no servidor. O Model é apresen-tado ao utilizador através de uma View, e esta manipula o Model através de uma interface RESTful JSON. A View pode definir callbacks para eventos do Model, que podem ser eventos relacionados com a mudança de estado dos atributos do Model, e que através desses callbacks a View mantém o estado da sua representação sempre atualizado. Com esta abordagem obtém-se um código que não inspeciona e nem depende de todo o DOM da aplicação para atualizar manualmente o HTML, uma vez que as Views estarão sempre atualizadas de acordo com as mudanças verificadas nos Models.
O Backbone.js é conhecido pela sua leveza e robustez, e a sua única dependência é a biblioteca Underscore.js, que por sua vez é dependente da biblioteca jQuery para intera-ções com o DOM. A biblioteca Underscore.js define templates para as Views, contendo elementos HTML e variáveis de template com a seguinte sintaxe:
1 . <%= n o m e _ v a r i a v e l %>
As Views passam as informações dos dados para representar nos templates em formato JSON. Por sua vez, os templates são responsáveis por corresponder os dados às variáveis de template. Na figura 2.9 está representado um template de uma View, responsável por fazer a iteração dos dados recebidos a partir da respetiva View. No final é apresentado uma lista com a descrição contida nos dados iterados. Este processo corresponde à ren-derização de uma View.
Figura 2.9: Exemplo de um Template de uma View Os principais componentes e ações do Backbone.js são os seguintes:
1. Models e Views - permitem manter a lógica do negócio separada da interface do utilizador. As tarefas responsáveis pelos Models são: coordenar os dados e a lógica
do negócio; carregar e guardar dados a partir do servidor; e emitir eventos quando os dados mudam. Enquanto que as Views contêm listeners para modificações que ocorrem nos Models; lidam com os inputs e as interações do utilizador; e enviam inputscapturados para os Models.
Por exemplo, considerando uma aplicação para a gestão de funcionários que per-mite a visualização da lista e dos detalhes dos funcionários. Quando um utilizador clica em obter os detalhes de um funcionário, esse evento é capturado pela View que por sua vez inicializa o Model (que irá conter os dados do utilizador) e faz um pedido ao servidor. Após a resposta do servidor, o Model é atualizado com os novos valores do funcionário. A View deteta que houve uma mudança no Model, e faz a renderização com os detalhes do funcionário. A figura 2.10 representa um exemplo deste tipo de interações.
Figura 2.10: Interação entre os models e as views.
2. Collections - uma Collection é um conjunto de models, responsável por carregar e guardar novos models para o servidor, fornecendo funções auxiliares para a realiza-ção de agregações ou cálculos.
Continuando o exemplo anterior, um utilizador ao adicionar um funcionário à sua aplicação, a View responsável por isso, irá detetar esse input e inicializar um novo Modelpara adicionar na base de dados. Assim que os detalhes do Model sejam in-seridos, a View deteta que foi adicionado um novo funcionário e recebe uma coleção com os detalhes de todos os funcionários. A figura 2.11 representa esse exemplo.
3. Renderização de Views - cada View gere a renderização e a interação do utilizador dentro do próprio DOM. As Views refletem os dados que os Models contêm. Existem duas formas de uma View ser renderizada. A primeira é quando um utili-zador realiza uma ação e espera que a mesma View seja novamente renderizada. A segunda é no caso de quando um utilizador clica, por exemplo num link, e os dados obtidos do servidor são representados por outra View. A figura 2.12 representa estas duas formas de renderização.
Figura 2.12: Representação da Renderização de Views
4. Routing com URLs - Nas aplicações web queremos providenciar URLs linkables, marcáveise partilháveis dentro da própria aplicação. Usamos o Router para atuali-zar o URL do browser sempre que o utilizador atinja um novo “lugar” na aplicação, em que pode querer marcar ou partilhar. Por outro lado, o Router consegue dete-tar mudanças no URL e pode dizer à aplicação exatamente onde se encontra. Por exemplo, se um utilizador clicar num link e este contenha a hashtag books (#books), é verificado a que Router pertence o “#books”. Assim que é detetado, é renderizada uma nova view. A figura 2.13 representa esse exemplo.
AngularJs
AngularJs é uma framework para desenvolver aplicações web dinâmicas sobre a arquite-tura MVC. Uma aplicação desenvolvida por AngularJs é definida por Modules que podem depender uns dos outros. Permite adicionar às páginas HTML novos atributos ou tags e expressões designados de Directives. Os Controllers são responsáveis pelo comporta-mento da aplicação, que ajudam a estruturar e a testar o código JavaScript mais facil-mente. Por último, o código pode ser facilmente fatorizado em Services que podem ser chamados nos Controllers.
O AngularJs é composto principalmente por:
1. Expressões - A fim de criar Views numa aplicação, o AngularJs permite executar expressões diretamente dentro das páginas HTML. A figura 2.14 representa uma expressão muito básica da soma entre dois números, em que o resultado é compu-tado dentro de quatro chavetas (ligação de dados).
Figura 2.14: Expressoes
2. Directives - As Directives são elementos incorporados e definidos no HTML, de forma a que a manipulação do DOM seja mais transparente e/ou para adicionar novos comportamentos às tags existentes. Um exemplo de uma Directive é o “ng-repeat”, que é utilizada para fazer iterações sobre um array e renderiza um template para cada elemento do array. Na figura 2.15 a Directive “ng-repeat”, faz iterações sobre o array names, em que para cada iteração faz renderização de um nome.
Figura 2.15: Diretiva ng-repeat
3. Controllers - O Controller é responsável pelo comportamento da aplicação. São usados para inicializar e/ou adicionar comportamentos à variável “$scope” e per-mitem fazer a comunicação com a View. Os controllers nunca devem ter nada re-lacionado com o DOM. A Directive “ng-controller” é utilizada para definir em que
parte do documento HTML será utilizada. Na figura 2.16, é exemplificado como o “$scope”, permite fazer a ligação entre a View e o Controller, em que o objetivo é renderizar o primeiro e o último nome de uma pessoa. Para isso, o Controller é inicializado na <div>, e a variável “$scope” é definida dentro da função “myC-trl” do Controller. Esta função é responsável por atribuir os valores às variáveis “firstName” e “lastName”, que serão renderizadas na View.
Figura 2.16: Diretiva ng-controller
4. Modules - Os Modules são componentes que inicializam e encapsulam os Control-lers, Directives, Services e Routes e são definidos pela Directive “ng-app”. A figura 2.17 representa um exemplo de um Module. Para criar um novo Module utiliza-mos a chamada “var app = angular.module("myApp", [])”. O primeiro parâmetro corresponde ao nome do Module, e o segundo parâmetro é um array com as depen-dências de que este Module está dependente. Neste caso o array está vazio, logo o Module corrente não depende de outros Modules. Para que o Module conheça o Controllerutilizamos a chamada “module.controller(...)”.
5. Services - Os Services são: Singletons, ou seja, cada componente dependente de um serviço obtém uma referência para uma única instância gerado pela serviço; lazily instantiated, isto é, o AngularJs apenas faz uma instância de um serviço quando uma componente da aplicação depende disso. Os componentes podem ser utiliza-dos para partilhar informações entre Controllers, servir como comunicação com o servidor e também para ser a camada que contém a lógica do negócio.
6. Routers - Esta componente permite criar diferentes URLs para diferentes páginas numa aplicação. Providenciam URLs linkables, marcáveis e partilháveis dentro da própria aplicação. Um Router é especificado no URL depois do símbolo hashtag. Na figura 2.18 é apresentado um exemplo de dois Routers, uma para os utilizadores e o segundo para outros Routers que são redirecionados para a página de erro. Por exemplo, se o URL acedido for “http://domain/#users”, o AngularJs irá carregar a View “users.html” e o Controller “UsersCtrl”. Para qualquer outro URL irá ser carregada a View “error.html”.
Figura 2.18: Representação de duas routes
O AngularJs apresenta o conceito de biding bidirecional ilustrado na figura 2.19. Em primeiro lugar o template (código HMTL com marcadores e/ou diretivas adicionais) é compilado no browser, em que a sua compilação gera uma View. Quaisquer modificações na View são refletidas imediatamente no Model, e quaisquer modificações no Model são propagadas na View. O Model é a única fonte com os dados para o estado da aplicação, o que simplifica a programação do Model para os developers. A View é uma simples projeção instantânea do Model. Devido à View ser uma projeção do Model, o Controller é completamente separado da View. Isto faz com que os testes sejam mais rápidos e organizados porque é fácil testar o Controller de forma isolada sem a dependência da Viewe do DOM/browser.
Figura 2.19: Binding Bidirecional Backbone vs AngularJs
Estas duas frameworks têm muitos aspetos em comum: ambas são opensource, e tentam resolver o problema de desenvolver SPA usando o design MVC e MV*. Ambas apresen-tam os conceitos de Models, Views, Events e Routing.
Na tabela 2.1.5 é feita uma comparação entre as duas frameworks:
Backbone.js AngularJS
Comunidade Pequena Grande
Tamanho da Framework Mais Leve Mais Pesada
Templating Depende de Terceiros
(ex: Underscore.js)
Não tem dependências
Aprendizagem Mais Fácil Mais Difícil
Arquitetura MV* MVC
Performance Mais Rápida Mais Lenta
Ligação de Dados
(Data Biding) Não Usa Bidirecional
Bootstrap
O Bootstrap é uma framework open-source usada no front-end para ajudar os developers a desenvolverem aplicações web responsivas usando o método RWD. Para além de conter os vários elementos de CSS, o Bootstrap apresenta um diversidade de componentes em JavaScript (jQuery) que ajudam o developer a implementar uma grande variedade fun-cionalidades, como por exemplo: tootlip8, menu-dropdown, modal, carousel, slideshow, etc. . . Esta framework é muito popular entre os designers e por isso existem muitas biblio-tecas e plug-ins desenvolvidos para esta framework. A figura 2.20 apresenta a disposição de três colunas com diferentes tamanhos num desktop. Ao usar as classes da framework
as três colunas irão adaptar-se aos diferentes tamanhos de ecrã. A figura 2.21 apresenta a disposição das três colunas num dispositivo com a largura de “790 pixels”.
Figura 2.20: Disposição de três colunas num desktop
Figura 2.21: Disposição de três colunas num dispositivo móvel
2.2
Casos de estudo
De forma a criar uma aplicação inovadora, foram identificadas as aplicações atualmente mais populares relacionadas com a pesquisa, divulgação e criação de eventos. Esta iden-tificação teve como base o maior número de transferências e ranking na PlayStore9, e a relevância dos resultados dados pela pesquisa realizada no Google10, para os casos de aplicações ımobile e web respetivamente. Foram analisadas quatro aplicações:All Events In City [29], EventBrite [11], Entrada Livre [5], e Airbnb [2].
Eventbrite
A aplicação Eventbrite permite aos utilizadores procurar e criar eventos. Esta é baseada na criação de eventos e como tal os organizadores podem planear, promover e vender bilhetes para os eventos que criam, como também promovê-los através das redes sociais, nomeadamente Facebook e Twitter.
Esta aplicação está disponível tanto para web como para mobile. No caso web, a aplicação é responsiva e adapta-se sem qualquer problema a diferentes tamanhos de ecrãs, usando o método RWD. Para o caso mobile a aplicação é nativa. Esta aplicação apresenta várias funcionalidades, nomeadamente:
Funcionalidades disponíveis para utilizador como não-organizador e como utili-zador autenticado
1. Pesquisar eventos por localidade, categoria, tipo de evento, data e preço; 2. Ver os eventos nos quais os seus amigos (do Facebook) vão participar;
9https://play.google.com/store 10https://www.google.pt/
3. Efetuar o registo e obter bilhetes para eventos;
4. Guardar os cartões de crédito ou débito para compras rápidas e fáceis; 5. Adicionar eventos ao Google Calendar;
6. Guardar eventos interessantes para ver mais tarde;
7. Ver os detalhes de cada evento, incluindo mapas e direções; 8. Adicionar eventos futuros ao calendário do utilizador; 9. Partilhar facilmente com os amigos do utilizador;
10. Adicionar interesses para que o sistema faça recomendações;
11. Entrar nos eventos pagos apenas mostrando o bilhete que se encontra no dispositivo móvel;
Funcionalidades disponíveis para utilizador como organizador e como utilizador autenticado
1. Procurar e registar os participantes no evento do utilizador a partir de uma lista de convidados;
2. Validar facilmente códigos de barras de bilhetes com a câmara do seu dispositivo; 3. Consultar as estatísticas de vendas e de participação no evento;
Esta aplicação apresenta como um ponto fraco a pesquisa de eventos em Portugal, nomeadamente em cidades que não sejam Porto e Lisboa. Por exemplo, na pesquisa pela localização “Viseu” os resultados apresentados são escassos, uma vez que a grande maioria dos eventos estão localizados fora da localização pesquisada, como exemplifica a figura 2.22.
Isto deve-se ao fato de a aplicação ser centrada na criação de eventos por parte dos utilizadores, e não utilizar um serviço externo para recolher eventos que ocorram em Portugal. Apesar de esta aplicação apresentar um mapa com um marcador a indicar a localização do evento, esta não permite ao utilizador obter direções para o evento a partir da sua localização atual. Na página do perfil do utilizador, não existe nenhum campo que permita indicar os interesses/gostos do utilizador, de modo a que possa receber sugestões de eventos. Contudo, é uma aplicação muito completa no que diz respeito às funciona-lidades de procura e criação de eventos. Apresenta uma interface, simples, intuitiva e com um bom design tanto na web como no mobile, o que obtém uma boa experiência do utilizador.
All Events In City
All Events In City é uma aplicação web que permite a pesquisa e a criação de eventos. Os eventos apresentados nos resultados de uma pesquisa são eventos criados no Facebook, ou seja, a aplicação usa a rede social como fonte para obter informações sobre os eventos, e obter os utilizadores que vão a um determinado evento. A aplicação para além da funcionalidade da criação de eventos, permite importar eventos que o utilizador criou a partir do Facebook. Esta aplicação está disponível tanto para web como para mobile. No caso web, a aplicação não é responsiva o que dificulta a visualização dos conteúdos em dispositivos com ecrãs pequenos. Para o caso mobile a aplicação é nativa. As principais funcionalidades desta aplicação, são as seguintes:
Funcionalidades do utilizador sem login
1. Procurar eventos por localidade, data, e categoria; 2. Adicionar um evento ao Google Calendar;
3. Visualizar o perfil do Organizador; Funcionalidades do utilizador com login 1. Criar eventos;
2. Importar eventos do utilizador através do Facebook; 3. Encontrar eventos baseado nos interesses do utilizador; 4. Gerir os seus eventos;
5. Receber notificações quando um utilizador é convidado por um amigo para par-ticipar no evento; e quando um organizador que o utilizador segue cria um novo evento;
7. Promover eventos; 8. Seguir organizadores; 9. Promover eventos; 10. Comentar o evento;
All Events In City é uma aplicação web muito completa no que diz respeito às suas funcionalidades. A funcionalidade promover eventos, permite ao utilizador subscrever serviços pagos de forma a publicitar o evento. Caso subescreva um serviço pago, o utili-zador poderá promover um determinado evento noutras localidades, personalizar a página do mesmo e obter um número ilimitado de convites por email.
Como ponto fraco, esta aplicação obtém também eventos “indesejáveis” criados no Facebook, uma vez que não apresenta um sistema que filtre/selecione esses eventos. Por exemplo, quando um utilizador efetua uma pesquisa pela keyword “Jorge Jesus”, aparece uma lista de eventos com títulos como, “Aulas de português com o Prof. Jorge Jesus”, “Reunião para criar um dicionário Português - Jorge Jesus; Jorge Jesus - Português”, etc. . . . Estes eventos são considerados como “indesejáveis” uma vez que não são fidedig-nos. A figura 2.23 exemplifica este exemplo.
Figura 2.23: Página que representa os resultados de uma pesquisa pela keyword Jorje Jesus
Apesar de esta aplicação apresentar um mapa com um marcador a indicar o local do evento, esta aplicação não permite obter direções para ir ao evento.
EntradaLivre
A EntradaLivre é um website que permite a pesquisa de eventos em Portugal, desen-volvido pelo Sapo. Os eventos apresentados por este website são recolhidos através do
serviço Agenda do SapoServices, o que confere uma grande variedade de eventos (so-bretudo culturais) que ocorrem em Portugal. Este website, não permite ao utilizador a possibilidade de criar os seus próprios eventos, limitando assim a partilha de conteúdo com outros utilizadores. Na página de um evento, apresenta recomendações de eventos similares ao evento que está a ser visualizado no momento. Por exemplo, se o utilizador visualizar um evento com o género música, irá recomendar eventos desse tipo de género. Este website apresenta algumas funcionalidades:
1. Filtros de pesquisa; 2. Login com Facebook; 3. Comentar o evento;
4. Permite ao utilizador dizer que vai a um determinado evento; 5. Ver que pessoas vão a um determinado evento;
6. Partilhar o evento por email, Facebook e Twitter; 7. Adicionar o evento ao Google Calendar;
8. Recomendar eventos similares;
Este website não é responsivo e por isso não se adapta aos diferentes tamanhos de ecrãs, o que dificulta a visualização do conteúdo em dispositivos móveis. Apresenta pouca interação com o utilizador, uma vez que apenas permite dizer que vai ao evento ou co-mentar o evento. Contudo, o ponto forte deste website, é a apresentação de uma grande variedade de eventos e informações sobre os mesmos. As figuras 2.24 e 2.25 representam a página inicial e a página de um evento, respetivamente.
Figura 2.25: Página de um evento do website EntradaLivre Airbnb
Apesar de não ser uma aplicação relacionada com eventos, importa fazer um caso de estudo sobre o seu funcionamento, pois apresenta funcionalidades e uma interface/usa-bilidade interessante. Para além disso, a sua popularidade tem vindo a crescer, com as pessoas em Portugal a terem uma participação muito ativa.
O Airbnb é uma aplicação web que permite aos utilizadores pesquisar, anunciar e reservar quartos e casas em todo o mundo. Esta aplicação permite a utilizadores comuns11 publicitar o seu espaço que querem arrendar. As pessoas, podem visualizar os anúncios, fazer uma reserva e contactar a pessoa responsável pelo anúncio.
Os utilizadores necessitam de se registar na aplicação e criar o seu próprio perfil antes de poderem utilizar as funcionalidades da aplicação. Cada anúncio está ligado a um host. Os clientes podem fazer recomendações ou reviews quer ao host quer aos espaços e tam-bém obtêm reviews por parte dos anfitriões. Isto permite dar aos utilizadores informação da qualidade dos espaços e garantia de que são reais. Por tudo isto, o Airbnb é a plata-forma número um de reserva de quartos e casas em todo o mundo. As funcionalidades mais relevantes são:
1. Página de pesquisa com os resultados apresentados numa lista que por sua vez está associada ao mapa;
2. Possibilidade de adicionar anúncios à uma Wishlist, que pode partilhar com os seu amigos;
3. Sistema de notificações;
4. Possibilidade de ver os anúncios criados;
5. Ver as suas reservas atuais e passadas;
O caso mais relevante no estudo desta aplicação web é a sua página com a lista de anúncios e o mapa. Esta página está divida em duas colunas, como mostra a figura 2.26.
Figura 2.26: Página da lista de anúncios
A coluna esquerda é responsável por apresentar os filtros de pesquisa relacionados com os anúncios. Por exemplo, o utilizador pode definir um intervalo de preço por qual quer pesquisar os anúncios. Apresenta também a lista de anúncios que está associada aos filtros de pesquisa selecionados.
A coluna direita é fixa ao contrário da coluna esquerda, e é onde o mapa é apresen-tado. No mapa estão presentes marcadores relacionados com os filtros de pesquisa e com a lista de anúncios que indicam o local do anúncio.
A interação com o mapa é uma funcionalidade relevante nessa página, pois a pes-quisa e a lista de anúncios estão interligados com o mapa. Quando alguns dos filtros de pesquisa são modificados, automaticamente a lista de anúncios é atualizada juntamente com o mapa, em que são colocados novos marcadores de acordo com esse resultado da pesquisa. Quando um utilizador passa o cursor do rato sobre uma imagem da lista de anúncios, automaticamente a cor do marcador relacionado a esse anúncio é modificado, isto serve para indicar que aquele anúncio corresponde aquele marcador, que por sua vez indica a localização do anúncio. A aplicação permite também que a lista de resultados seja atualizado à medida que o utilizador navega no mapa.
Para além disto tudo, a aplicação é responsiva (usa o método RWD), ou seja, o seu conteúdo adapta-se de acordo com o tamanho de ecrã.
2.2.1
Comparação de Funcionalidades
Para além das funcionalidades já existentes do projeto “Onde há Bola?”, nomeadamente a visualização dos resultados da pesquisa no mapa, da search box e a intenção de um
