Técnicas e tecnologias para desenvolvimento de Front-End na empresa PontoPR - Inovação Digital

Universidade de Trás-os-Montes e Alto Douro

Técnicas e Tecnologias para Desenvolvimento de

Front-End na empresa PontoPR - Inovação Digital

Relatório de Projeto de Mestrado em Comunicação e Multimédia

Por:

Moisés Silva de Paiva

Orientador: Emanuel Soares Peres Correia

Coorientador: Telmo Miguel de Oliveira Adão

III

Universidade de Trás-os-Montes e Alto Douro

Técnicas e Tecnologias para Desenvolvimento de

Front-End na empresa PontoPR - Inovação Digital

Relatório de Projeto de Mestrado em Comunicação e Multimédia

Por:

Moisés Silva de Paiva

Orientador: Emanuel Soares Peres Correia

Coorientador: Telmo Miguel de Oliveira Adão

V

Agradecimentos

A realização deste relatório de projeto marca o fim de uma importante etapa da minha vida e por isso gostaria de agradecer a todas as pessoas que, direta ou indiretamente, contribuíram de forma decisiva para a sua concretização.

À minha família, pais e irmão, que sempre me apoiaram nos momentos mais difíceis e demonstraram imensa compreensão. Aos meus tios e primos por todas as palavras de encorajamento durante a minha vida académica.

À minha namorada Andreia que esteve sempre presente, sendo um pilar para mim, e dispensou tempo precioso para que este projeto se pudesse realizar, apoiando-me sempre e exigindo sempre mais e melhor de mim, acreditando sempre nas minhas capacidades.

Aos meus orientadores, Emanuel Peres e Telmo Adão, pela excelente orientação desde o início, pelo empenho e disponibilidade que sempre demonstraram, pela paciência, dedicação, simpatia e rigor. Sem eles não seria possível a conclusão deste relatório de projeto.

Aos meus/minhas colegas e amigos/as da PontoPR que sempre estiveram disponíveis para me ensinar, esclarecer qualquer dúvida e me incentivaram, enriquecendo ainda mais a minha aprendizagem como profissional e como pessoa.

À UTAD, a mui nobre academia e à cidade de Vila Real que me acolheram ao longo de cinco anos e me disponibilizaram todas as condições para a minha formação académica.

Ao Magnífico Reitor da Universidade de Trás-os-Montes e Alto Douro, Professor António Augusto Fontainhas Fernandes e ao Presidente da Escola de Ciências e Tecnologia, José Boaventura Cunha pelas facilidades e meios previstos para a realização deste projeto.

À família Sinfonia da UTAD, Ivo Mendes, Cláudio Reguengo, Bruno Silva, Tiago Capitão, Francisco Soares, Luís Matos, que descanse em paz, e meu grande irmão Jorge Ferreira, por todos os momentos inesquecíveis ao longo de cinco anos e que levo na bagagem para toda a vida.

VI

À família académica, Rita Namora, Daniel Matos, Ema Almeida, Cristiana Carvas, José Miranda e Liliana Babo, que enriqueceram a minha vida académica e que levo igualmente na bagagem para toda a vida.

À família Memes da Casa, José Santos, Nádia Pimenta, Márcia Freitas e Nuno Severino, que foram os melhores colegas de casa e com quem partilhei momentos incríveis que se transformaram numa amizade vitalícia.

Aos meus amigos de sempre, Patrick Maravilha, Pedro Paiva, Fabrício Ribeiro, Diogo Montenegro, Cláudio Oliveira, Leandro Valente, Tiago Barbosa, Jorge Paiva, Diogo Ferreira, Ivo Paiva, Nélson Paiva, Daniel Ferreira, Roberto Paiva e irmãos Vasconcelos, com os quais preservo uma amizade inabalável.

Aos meus grandes amigos e exemplos de profissionalismo, João Nascimento e Marco Ferreira, por todos os conselhos, orientações, amizade e incentivo em todo o decorrer do mestrado.

Aos meus colegas do Núcleo de Estudantes de Comunicação e Multimédia, que durante três anos me fizeram crescer como pessoa e com quem vinculei uma forte amizade.

Por fim agradeço a todas as pessoas que de algum modo estiveram presentes no meu percurso académico e o influenciaram positivamente.

VII

Resumo

A forma como os utilizadores acedem à informação transformou-se significativamente nos últimos anos, principalmente com a expansão de diversos dispositivos, desde computadores fixos, portáteis, tablets e smartphones. Devido aos diversos tamanhos de ecrã dos dispositivos, foi necessário adaptar o desenvolvimento das páginas web e tornar todos os elementos adaptáveis a qualquer tamanho de ecrã.

Respondendo ao desafio de adaptar convenientemente os conteúdos ao contexto do dispositivo do utilizador, várias técnicas e tecnologias de front-end têm vindo a surgir, trazendo grandes benefícios ao desenvolvimento de projetos de pequena ou larga escala, em que as equipas integrantes podem variar em tamanho e valências.

Seguindo a linha definida pela temática inerente ao layout responsivo, neste documento serão analisadas diversas técnicas e tecnologias para o desenvolvimento e gestão de projetos multimédia da PontoPR - Inovação Digital, empresa sediada em Vila Nova de Gaia e ligada ao ramo do desenvolvimento web e marketing digital. Serão, também, apresentados os diversos projetos implementados desde sítios web a comércio eletrónico para empresas de renome nacional e internacional. Todos esses projetos foram desenvolvidos em contexto de cooperação com uma equipa multidisciplinar integrada na empresa PontoPR e usando a metodologia SCRUM para o planeamento e gestão de tarefas de cada projeto.

IX

Abstract

The way users access information has changed significantly in recent years, especially with the expansion of various devices, from desktops, laptops, tablets and smartphones. Due to the various screen sizes of the devices, it was necessary to adapt the development of web pages and make all elements adaptable to any screen size.

Responding to the challenge of conveniently adapting content to the user's device context, a number of front-end techniques and technologies have emerged, bringing great benefits to the development of small- and large-scale projects in which component teams can vary in size.

Following the line defined by the inherent theme to the responsive layout, this document will analyze various techniques and technologies for the development and management of multimedia projects of PontoPR - Inovação Digital, a company based in Vila Nova de Gaia and linked to the web development and digital marketing. Several projects ranging from websites to e-commerce implemented for companies of national and international reputation will also be presented. These projects were developed in cooperation with a multidisciplinary team integrated in the PontoPR company and using the SCRUM methodology for planning and managing the set of tasks involved in each project.

XI

Índice

2.1. Gestão de projetos multimédia ... 6

2.1.1. Metodologias de desenvolvimento ágil ... 6

2.1.2. Kanban ... 7

2.1.3. Scrum ... 9

2.1.4. Sistema de controlo de versões Git ... 15

2.2. Responsive Web Design ... 16

2.3. Search Engine Optimization (SEO) ... 19

2.4. Frameworks de desenvolvimento front-end ... 20

2.4.1. Bootstrap ... 22

2.4.2. Foundation ... 24

2.4.3. Comparação entre o Bootstrap o Foundation ... 26

2.5. Content Management System (CMS) ... 27

2.5.1. Umbraco ... 28

2.5.2. NopCommerce ... 29

3. Projetos ... 32

3.1. Landing Page 906.pt ... 32

3.2. Website da Leitaria da Quinta do Paço ... 34

3.3. Landing Page Clínica Médico-Estética Avançada (MEA) ... 36

XII

3.5. E-commerce Rio Sul ... 39

3.5.1. Design e layout ... 43

3.5.2. Gestão de produtos ... 48

3.5.3. Plugins desenvolvidos ... 52

3.5.4. Área administrativa ... 62

3.6. Outras participações ... 63

3.6.1. Espaço municipal da Maia ... 63

3.6.2. House Teixeirinha Restaurant ... 63

3.6.3. Civilspot ... 64

3.6.4. Sistrade – Software Consulting, S.A. ... 65

3.6.5. Taminno ... 65

4. Conclusões e trabalhos futuros ... 68

XIII

Índice de Figuras

Figura 1 - Quadro de um projeto Kanban. ... 9 Figura 2 - Eventos da metodologia Scrum. ... 10 Figura 3 - Lista de tarefas da equipa PontoPR no primeiro sprint de 2107 (02 a 13 de Janeiro) no Microsoft Team Foundation Server. ... 13 Figura 4 - Exemplo de um Sprint Burndown Chart da equipa PontoPR na primeira sprint de 2107 (02 a 13 de Janeiro)... 14 Figura 5 - Funcionamento básico do controlo de versões Git. ... 16 Figura 6 - Exemplo de uso de Media Queries. ... 17 Figura 7 - Disposição do mesmo conteúdo em diferentes dispositivos Fonte:

www.civilspot.com. ... 18 Figura 8 - Nível de procura das duas versões mais usadas do Bootstrap e Foundation com base no Google Trends. ... 21 Figura 9 - Sistema de grelhas do Bootstrap Fonte: http://getbootstrap.com/css/. ... 22 Figura 10 - Sistema de grelha do Bootstrap representado em cada tipo de dispositivo. Fonte:

http://www.tutorialrepublic.com/twitter-bootstrap-tutorial/bootstrap-grid-system.php. ... 23 Figura 11 - Página de personalização da base de um projeto em Foundation Fonte: http://foundation.zurb.com/sites/download.html/. ... 25 Figura 12 - Bases de projetos em HTML fornecidas pelo Foudation Fonte:

http://foundation.zurb.com/templates.html... 26 Figura 13 - Back-office do Umbraco do projeto Medical Design realizado pela PontoPR Fonte: http://www.medicaldesign.pt/. ... 29 Figura 14 - Exemplo de uma loja e da sua área Fonte:

www.nopcommerce.com/demo.aspx. ... 30 Figura 15 - Maquete da landing page 906.pt. ... 33 Figura 16 – Resultado final da implementação da landing page. Fonte: www.906.pt. .. 34 Figura 17 – Resultado final da implementação do módulo de Imprensa com uso do Bootstrap Carousel. Fonte: http://www.leitariadaquintadopaco.com/imprensa/2016/. .. 35 Figura 18 - Resultado final da primeira versão da landing page. ... 36 Figura 19 - Resultado final da segunda versão da landing page Fonte:

http://www.clinicamea.com/ ... 37 Figura 20 - Pergunta 5 do questionário onde é possível escolher apenas uma das caras como resposta. O plugin só permite avançar para a próxima pergunta depois de fazer uma escolha. ... 38 Figura 21 - Fase final do questionário onde é possível fazer uma revisão a todas as respostas podendo alterar qualquer resposta antes de submeter o questionário. ... 39 Figura 22 – Maquete da Página Inicial. ... 41 Figura 23 - Planeamento de desenvolvimento do projeto Rio Sul. O front-end foi

dividido em partes da lojas, tal como a Homepage e Área de Cliente, e por módulos a serem construídos de raiz como por exemplo o módulo de Catálogos de produtos. Foi

XIV

criado um ramo para cada tarefa e cada ramo é descendente do ramo frontend sendo

este descendente do ramo principal do projeto, o ramo develop. ... 43

Figura 24 - A caixa de informação aparece quando o cursor do rato estiver em cima do ícone do carrinho. ... 44

Figura 25 - Menu em dispositivo móvel. ... 45

Figura 26 - Resultado final da implementação do Nivo Slider ... 46

Figura 27 - Disposição das páginas/vistas do projeto... 47

Figura 28 - Rodapé atualizado e Newsletter inserida no final da página inicial ... 47

Figura 29 - Listagem dos produtos referentes à categoria Linha de Mesa e o seu menu lateral para que o utilizador possa escolher outra categoria ou subcategoria. ... 48

Figura 30 - Resultado da implementação da vista parcial _ProductBoxList que é carregada sempre que utilizador selecione a opção de visualizar os produtos em lista. 50 Figura 31 - Resultado final da implementação dos presentes numa página de informação de um produto. ... 51

Figura 32 - Vista da caixa/janela popup depois de o utilizador carregar no botão “Catálogo” do produto retratado. ... 53

Figura 33 - Exemplo de uma lista de catálogos: um já foi gerado criado e fechado e encontra-se, por isso, desabilitado para edições, enquanto um segundo catálogo pode ser editado carregando no ícone do lápis. ... 54

Figura 34 - Implementação provisória da página de criação/edição de catálogos contendo os elementos especificados pela equipa de desenvolvimento e aprovados pelo cliente. ... 55

Figura 35 - Área reservada à criação de ambiente, que permite a colocação de etiquetas descritivas em partes estratégicas da imagem que representam uma peça têxtil. ... 58

Figura 36 – Maquete representando a listagem de três ambientes previamente criados em que podem ser listados consoante a data de criação, nome, categoria e visibilidade. ... 60

Figura 37 – Visualização provisória de um ambiente selecionado no slider de imagens pelo cliente. É possível , ainda, clicar num marcador e visualizar que produto está associado ao mesmo sendo que o produto fica evidenciado numa lista reservada para o efeito. ... 61

XV

Glossário, Acrónimos e Abreviaturas

Glossário de termos

Browser - aplicação que permite aos utilizadores da internet consultarem documentos

em hipertexto, permitindo ainda o acesso a outros recursos dessa rede.

Desktop - designa o ambiente principal do computador ou o tipo de ecrã associado a

computadores.

Framework - conjunto de classes implementadas numa ou mais linguagens específicas,

usadas para auxiliar o desenvolvimento web.

Landing Page - página de destino ou de entrada por onde o utulizador chega num website, quando clica num resultado de busca natural ou uma ação de links

patrocinados.

Layout - tem como seus componentes a área de design ou formato de página e as

margens definindo todo o aspeto a apresentar.

Mobile First – desenvolvimento e planeamento de projetos web primeiramente para

dispositivos móveis e somente depois para dispositivos de maior largura de ecrã.

Open Source - em português, código livre, refere-se a todo software livre. Plugin – módulo de extensão.

Slider - dispositivo dinâmico de apresentação de imagens.

Lista de acrónimos

API – Applicacation Program Interface CSS - Cascading Style Sheets

CMS - Content Management System HTML - HyperText Markup Language JS - Javascript

XVI

MTFS - Microsoft Team Foundation Server RWD - Responsive Web Design

SEO - Search Engine Optimization UI - User Interface

UX- User Experience WIP - Work in Progress

2

1. Introdução

O desenvolvimento web reúne diversos tipos de profissionais, tais como, front-end,

back-end, e full stack developers. O front-end developer foca-se no desenvolvimento

das interfaces gráficas com as quais o utilizador opera. Já o back-end developer foca-se no desenvolvimento no lado do servidor, ou seja, nas regras de negócio presentes num sistema de informação baseado na Web. Destaca-se, ainda, o full stack developer, que opera tanto na parte do front-end e back-end (Nice, 2017). Dos três tipos de desenvolvimento abordados, o presente documento centrar-se-á no front-end, uma vez que na base deste mestrado está um portfólio de trabalhos realizados no âmbito de um estágio curricular, durante o qual foram desempenhadas tarefas ligadas à produção da parte visual e interativa de websites. O referido estágio curricular decorreu no seio da PontoPR – Inovação digital que é uma empresa que foca os seus principais serviços no desenvolvimento de websites, comércio eletrónico, marketing digital e web design.

O termo front-end corresponde à estrutura hierárquica de conteúdo e à aplicação visual de uma plataforma na web(Lindley, 2017). O front-end developer é responsável pelo desenvolvimento do material visual de um website (parte da frente) e de toda a interação (user experience) do mesmo, feito ou não em conjunto com o web designer, pela compatibilidade entre os diferentes browsers, produção de código limpo (Lindley, 2017), bem documentado e estruturado bem como a aplicação técnicas de SEO (Search

Engine Optimization). O desenvolvimento de um bom front-end é fulcral para o sucesso

de um website ou aplicação web, dada a importância que a qualidade da implementação da estrutura e da interação têm no impacto da experiência do utilizador.

O desenvolvimento de front-end tem vindo a ganhar relevância devido à rápida taxa de atualização dos conteúdos e às nuances de apresentação dos mesmos que variam de dispositivo para dispositivo, facto que se continua a verificar mesmo após o surgimento das tecnologias emergentes, nomeadamente, HTML5/CSS3, o que, por sua vez tem vindo a potenciar a disponibilização de interfaces de programação de aplicações (API’s) em torno destas tecnologias com o intuito de tornar o processo de desenvolvimento mais efetivo e fácil de gerir. Algumas destas API’s serão abordadas neste documento, através da implementação de projetos web, tais como páginas web e comércio eletrónico, desenvolvidos em ambiente empresarial e seguindo boas normas de web design responsivo.

3

1.1. Motivação

Visando um real contacto na conceção de projetos multimédia em ambiente empresarial, o presente relatório de projeto visa a compreensão e a participação no processo de desenvolvimento de projetos multimédia em ambiente empresarial bem como a compreensão e aplicação de boas técnicas de desenvolvimento de front-end.

1.2. Objetivos

Através do envolvimento direto nos projetos à responsabilidade da PontoPR respeitando, simultaneamente, as metodologias de desenvolvimento instauradas na empresa, os seguintes objetivos foram delineados para a realização deste trabalho:

 Compreender e aplicar ágil Scrum como metodologia de desenvolvimento de soluções de software adotada como convenção pela empresa.

 Uso de Controlo de Versões GIT.

 Compreender e aplicar a framework de desenvolvimento front-end Bootstrap para implementação dos layouts dos projetos.

 Estudar e usar sistemas de gestão de conteúdos Umbraco para a criação de

websites institucionais bem como NopCommerce para a conceção de

comércios eletrónicos.

 Criação de temas responsivos apresentáveis e eficientes para futuros projeto.

1.3. Organização do documento

O presente relatório encontra-se dividido em cinco capítulos, para além da introdução, o segundo capítulo retrata o estado da arte, onde é feita uma revisão bibliográfica sobre técnicas, tecnologias e conceitos ligados ao desenvolvimento

front-end bem como os que a PontoPR usa.

No terceiro capítulo são apresentados todos os projetos desenvolvidos, no qual se enquadram os requisitos relativos a cada um, bem como o planeamento, implementação e resultados. Para além das imagens inerentes ao layout final de cada projeto, também os endereços web são fornecidos para consulta online.

4

O quarto capítulo é referente às conclusões obtidas na realização do relatório, uma revisão geral sobre tudo o que foi feito, desafios, dificuldades, adequação das metodologias de trabalho, bem como adequação das tecnologias usadas à concretização do desenvolvimento dos projetos. São também definidas espetativas para futuros projetos.

6

2. Desenvolvimento em front-end

Neste capítulo é feita uma revisão bibliográfica de algumas tecnologias e técnicas, de forma a abordar as políticas de gestão e desenvolvimento de projetos seguidas na PontoPR, bem como as tecnologias web adotadas.

2.1. Gestão de projetos multimédia

As empresas/agências de desenvolvimento web enfrentam, atualmente, um grande desafio de competitividade e de adaptação a mudanças rápidas para se manterem credíveis e capazes de responder aos desafios de mercado. É difícil adaptar o processo de desenvolvimento e gestão dos projetos face à demanda de soluções com especificidades muito próprias e níveis de complexidade variáveis. Antes dos produtos finais serem lançados, eles passam por um processo de desenvolvimento, na maioria das vezes caracterizado por uma fase inicial de criação e concetualização, seguida pela produção, teste e validação. Tendo em conta a quantidade de áreas de conhecimento que podem convergir para um projeto multimédia e a quantidade de tarefas realizadas por diferentes membros da equipa de desenvolvimento, é necessário um conjunto de métodos, técnicas e ferramentas de apoio para que os objetivos do projeto possam ser alcançados nos devidos prazos (Lei, Ganjeizadeh, Jayachandran, & Ozcan, 2017). É também necessário considerar o impacto que as interações de todos os envolvidos no desenvolvimento podem ter na produtividade. As metodologias de desenvolvimento ágil são vistas como uma possível resposta às exigências das atuais equipas de desenvolvimento (Seabra & Almeida, 2015).

2.1.1.

Metodologias de desenvolvimento ágil

Projetos de desenvolvimento web/software requerem certos tipos de metodologias de desenvolvimento e serviços inovadores, com um conjunto distinto de conhecimentos e métodos de trabalho. Em 2001, metodologias tradicionais tais como a Vee ou a Waterfal que não possuíam uma eficácia necessária para atender às necessidades dos

7

clientes, foram discutidas e o Manifesto para Desenvolvimento de Software Ágil foi publicado para definir a estrutura e os objetivos de novos métodos de desenvolvimento (Lei, Ganjeizadeh, Jayachandran, & Ozcan, 2017).

Para melhorar o processo de desenvolvimento e gestão de projetos, as metodologias ágil fornecem um conjunto de práticas e adaptações rápidas para corresponder às necessidades de desenvolvimento de produtos que satisfaçam as necessidades do cliente e, ao mesmo tempo, melhorar a comunicação e colaboração da equipa de desenvolvimento.

As Metodologias Kanban e Scrum são duas poderosas abordagens de gestão de projetos ágil no desenvolvimento web, sendo que o objetivo de ambas é a otimização dos processos de desenvolvimento, identificando as tarefas e equipas integrantes e assegurando uma gestão mais eficaz dos tempos. Nos dois pontos seguintes, serão apresentadas as principais características de ambas as metodologias.

2.1.2.

Kanban

Kanban é uma ferramenta para a gestão no desenvolvimento de software que tem, como foco, o trabalho certo no momento certo, dadas as características de cada membro da equipa de desenvolvimento. Ficou conhecida no momento em que a Toyota Motor Corporation arriscou aplicá-la (Naufal, Jaffar, Yusoff, & Hayati, 2012). O uso do sistema Kanban melhorou a eficiência e flexibilidade de fabricação da Toyota de acordo com as necessidades do cliente.

No desenvolvimento de software, foi o então diretor sênior de engenharia da Corbis David J. Anderson que decidiu projetar a metodologia Kanban em 2006. Em janeiro de 2007 as melhorias de processos começaram a estagnar. Darren Davis, gerente de desenvolvimento, sugere a David J. Anderson que o fluxo de trabalho deveria ser visualizado e que um quadro branco com alguns cartões colados deveria ser pendurado na parede, tal como na Figura 1. Com o passar dos meses, novas atualizações como, limite de quantidade de trabalho em andamento chamado de Work in Progress (WIP), foram implementadas. Os resultados preliminares do uso da metodologia Kanban na Corbis foram apresentados nas conferências Lean New Product Development e Agile 2007 (Anderson & Reinertsen, 2010).

8

A metodologia Kanban apresenta explicitamente as tarefas mais importantes que necessitam de maior prioridade, a fim de reduzir o risco que fiquem incompletas e também aumentar a flexibilidade entre outras tarefas do projeto (Anderson & Reinertsen, 2010).

Esta metodologia apoia-se nos seguintes 5 princípios básicos:

 Visualizar o fluxo de trabalho.

 Limitar a quantidade de trabalho em progresso/WIP.

 Gerir e medir o fluxo de trabalho.

 Tornar as políticas do processo explícitas.

 Usar modelos para reconhecer oportunidades de melhoria.

Cada membro tem diferentes conjuntos de habilidades e ritmos de trabalho. A equipa de desenvolvimento começa por implementar componentes do projeto que lhe agreguem valor. Além disso, a equipa de desenvolvimento não implementa recursos desnecessários, não escreve mais especificações do que pode codificar e não escreve mais código do que pode testar. (Lei, Ganjeizadeh, Jayachandran, & Ozcan, 2017).

A visualização do fluxo de desenvolvimento que mostra a evolução do projeto é um aspeto significativo da metodologia Kanban. Um quadro Kanban, representado na Figura 1, é usado para visualizar o processo, as tarefas e os objetivos do projeto em desenvolvimento. Todas as etapas e tarefas necessárias para a implementação do projeto são claramente identificadas e todas as tarefas necessárias são escritas em cartões ou notas adesivas e adicionadas ao backlog do quadro. É importante que os cartões possuam informações simples e descritivas. As tarefas no backlog passam por um número de etapas até que sejam concluídas. Para entregar o projeto no prazo estipulado são colocados limites no número máximo de tarefas em cada etapa. Caso uma das etapas tenha menos tarefas do que o que os limites especificados, pode-se acrescentar mais tarefas na mesma. Caso contrário, as tarefas já definidas devem ser concluídas antes de se acrescentar novas à etapa.

9

Figura 1 - Quadro de um projeto Kanban.

Usando os cartões coloridos, facilita a visualização do fluxo de trabalho para a equipa de desenvolvimento, a gestão das limitações de tempo desenvolvimento, o custo do projeto e os prazos estipulados.

2.1.3.

Scrum

Scrum é uma metodologia de desenvolvimento de software ágil que usa repetição e incremento. Foi projetada para gerir requisitos, controlar riscos e otimizar a previsibilidade de um projeto, melhorando a comunicação entre os membros da equipa de desenvolvimento, clientes projetos e outros membros da equipa. Foi definida, formalizada e publicada como a primeira metodologia de desenvolvimento ágil (Lei, Ganjeizadeh, Jayachandran, & Ozcan, 2017). Em 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna, da Easel Company, usaram a metodologia Scrum para projetos de desenvolvimento de software pela primeira vez (Sutherland, 2004).

Três pontos são essenciais para que a metodologias Scrum funcione (Schwaber & Sutherland, n.d.):

 É necessário existir transparência para que o processo seja visível para todos os envolvidos no projeto.

10  É necessário haver inspeção para que todos os requisitos do projeto sejam

estudados inicialmente para garantir que não surjam grandes problemas no decorrer do projeto.

 É necessária adaptação, caso o Scrum Master determinar que alguns aspetos do projeto não se adequam ao bom desenvolvimento do projeto, o processo pode ser ajustado para evitar mais problemas.

Figura 2 - Eventos da metodologia Scrum.

É absolutamente importante aplicar esses fatores durante as diferentes fases de desenvolvimento de um projeto. Os detalhes relativos a esses fatores são apresentados nas seções a seguir em que a metodologia Scrum é composta por três elementos fulcrais sendo eles:

 Product Owner: É o dono do produto ou projeto que vai ser desenvolvido, sendo responsável pela coordenação do desenvolvimento, definindo quais os requisitos presentes no product backlog e quais devem ser abordados pela equipa, sendo o único a poder fazê-lo. Representa o(s) cliente(s) do produto;

 Scrum Master: É o elemento que faz a ligação entre o product owner e a equipa de desenvolvimento. Tem a responsabilidade de organizar reuniões, fazer o acompanhamento do trabalho e se certificar que cada membro da equipa tem as ferramentas necessárias para cumprir a sua função da melhor maneira possível;

11  Equipa de desenvolvimento: É responsável pela entrega do produto. A

equipa é, no geral, composta de 5 a 9 elementos com habilidades multifuncionais e com o objetivo de analisar, projetar, desenvolver, testar técnicas de comunicação e documentar. São também autorizadas e incentivadas pela própria empresa a organizar e gerir o seu próprio trabalho;

Existem eventos, vistos na Figura 2, definidos na metodologia Scrum de forma a criar uma rotina de trabalho e minimizar reuniões não definidas. Todos os eventos têm uma duração máxima e uma vez que a Sprint começa a sua duração não pode ser reduzida nem aumentada. A metodologia Scrum é composta pelos seguintes eventos:

 Sprint: É a peça principal da metodologia Scrum, é o período de tempo em que a primeira versão do produto é criada e desenvolvida. As sprints são compostas por uma reunião de planeamento da sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da sprint e a retrospetiva da sprint. Cada sprint pode ser considerada um projeto de duração não maior que um mês. Tais como os projetos, as sprints são utilizadas para realizar tarefas. Cada sprint tem a definição do que é para ser construído, um plano projetado e flexível que irá guiar a construção, o trabalho e o resultado do produto.

 Reunião de planeamento da sprint: O trabalho a ser realizado na sprint é planeado na reunião de planeamento da sprint. Este plano é criado com o trabalho colaborativo de todo a equipa Scrum (Product Owner, Scrum Master e equipa de desenvolvimento). A reunião de planeamento da sprint possui uma duração máxima de oito horas para uma sprint de um mês. Para sprints menores, este evento é geralmente menor. O Scrum Master garante que o evento ocorra, que os participantes entendam seu propósito e ensina a equipa a manter-se dentro dos limites de tempo de desenvolvimento.

 Reunião Diária: É um evento de 15 minutos, para que equipa de desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta reunião é feita para verificar o trabalho desde a última reunião diária e prever o trabalho que deverá ser feito antes da próxima reunião diária. É feita no mesmo horário e local todos os dias.

12  Revisão da sprint: A revisão da sprint é executada no final da sprint para

adaptar o backlog do Produto se necessário. Durante a reunião, a equipa Scrum e as partes interessadas colaboram sobre o que foi feito na sprint. Com base nisso e em qualquer mudança no backlog do produto durante a sprint, os participantes colaboram nas próximas tarefas que podem ser feitas para otimizar o desenvolvimento. Esta é uma reunião informal e destina-se a motivar, comentar e promover a colaboração.

 Retrospetiva da sprint: é uma reunião de duração máxima de 3 horas e ocorre ao final de uma sprint. Tem como principal função identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

No contexto da metodologia Scrum, dois tipos de backlog foram referidos. Eis as diferenças entre eles:

 Product backlog: é uma lista de todas as funcionalidades desejadas do produto. O conteúdo desta lista é definido pelo product owner. O product backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio, por exemplo, no desenvolvimento de um website, o mesmo possui geralmente, cabeçalho e rodapé ou seja podem ser as duas primeiras tarefas a serem criadas. Com o tempo, o product backlog cresce e muda à medida que se aprende mais sobre o produto e os seus utilizadores. (Schwaber & Sutherland, n.d.) Durante a reunião de planeamento da sprint, o

product owner prioriza os itens do product backlog e os descreve para a equipa.

A equipa então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do product backlog para o

sprint backlog. Ao fazer isso, a equipa quebra cada item do product backlog em

uma ou mais tarefas do sprint backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do product backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

 Sprint backlog: é uma lista de tarefas que a equipa Scrum se compromete a fazer numa sprint. Os itens do sprint backlog são extraídos do product backlog, pela equipa, com base nas prioridades definidas pelo broduct owner e a perceção da equipa sobre o tempo que será necessário para completar as tarefas. A equipa é que determina a quantidade de itens do product backlog que serão trazidos

13

para o sprint backlog, já que é a equipa que irá desenvolver as tarefas. O sprint

backlog pode ser criado à mão num quadro físico ou com recurso a ferramentas

de desenvolvimento colaborativas, tal como o Microsoft Team Foundation Server, exemplificado na Figura 3, que integram painéis Scrum com a possibilidade de criar tarefas, atribuir, priorizar, manter registo do estado e do tempo de execução das tarefas, entre outras funcionalidades inerentes à gestão do desenvolvimento. Todas as alterações no código são vinculadas diretamente ao histórico com o uso de um controlo de versões interligado a um editor de código (Paolini, 2016).

Figura 3 - Lista de tarefas da equipa PontoPR no primeiro sprint de 2107 (02 a 13 de Janeiro) no Microsoft Team Foundation Server.

.

O Scrum Master é o encarregado do sprint backlog, atualizando-o para verificar o estado das tarefas e quanto tempo a equipa acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feita na Sprint, é calculada diariamente e colocada num gráfico, resultando num Sprint

14

Figura 4 - Exemplo de um Sprint Burndown Chart da equipa PontoPR na primeira sprint de 2107 (02 a 13 de Janeiro).

Fazendo um balanço das duas metodologias descritas em cima, Kniberg e Skaring afirmam que as metodologias Kanban e Scrum são semelhantes, não só por serem ágeis, mas, igualmente, por possibilitarem a divisão de trabalho e a organização de equipas de desenvolvimento independentes e concentradas em fornecer resultados dentro dos prazos estipulados de forma frequente, bem como pela rapidez na adaptação às mudanças e à propensão para a redução de ocorrências WIP. (Kniberg & Skarin, 2010). Uma das características mais importantes que têm em comum é a transparência que garante que todos os fatores e aspetos que possam vir a afetar o resultado final estejam visíveis e sejam do conhecimento de todos os envolvidos, inclusive o cliente. No entanto existem diferenças entre as duas metodologias. Por exemplo, a metodologia Kanban pode lidar com bastantes interrupções no projeto e com uma equipa de desenvolvimento com diferentes conjuntos de habilidades. Também funciona bem para equipas maiores, uma vez que as despesas gerais de comunicação e planeamento são menores. Por outro lado, a metodologia Scrum é mais apropriada para projetos que exijam uma colaboração e inovação profunda, envolvendo pequenas equipas multifuncionais (Sahota, 2010).

15

2.1.4.

Sistema de controlo de versões Git

No desenvolvimento web e de software, em equipa, é muito comum o acesso concorrente ao mesmo recurso por diferentes elementos. Para evitar problemas de edição, conflitos, manter um registo do histórico do desenvolvimento, o que permite controlar evoluções, identificar problemas nas abordagens de implementação, reverter para versões estáveis, rapidamente, é necessário um sistema de controlo de versões. Estes sistemas vinculam automaticamente uma determinada edição a uma data e a um elemento integrante da equipa de desenvolvimento, aquando da submissão de alterações. Para além disso, oferecem ainda mecanismos de resolução de conflitos, para situações de edição concorrencial. Cada vez que uma ou mais alterações são feitas num ficheiro, as mesmas podem ser confirmadas e enviadas para o repositório com uma descrição, essa ação é designada de commit, que, em português, significa entrega, envio ou consignação ao outro lado. (Scott, Johnston, & Cox, 2017).

De entre os muitos sistemas de controlo de versões existentes, os mais usados são CVS, Subversion, Git (é opensource) e Mercurial (O’Sullivan, 2009). No Git o commit é inicialmente feito localmente antes de ser enviado para qualquer outra cópia do repositório do projeto. Geralmente, uma das cópias é nomeada para ser a cópia central, ou seja, será a cópia que receberá todas as alterações feitas por todos os membros da equipa de desenvolvimento, através das suas cópias locais correspondentes. Cada cópia é designada de branch, o que significa que cada cópia é um ramo pertencente a uma ramificação.

Para criar um branch local e atualizado basta criá-lo a partir do branch que contenha a versão atualizada do projeto, ou seja, pode-se considerar que o branch local criado, é uma cópia do branch atualizado. Essa característica única do Git é chamada de

branching ou em português é traduzida para ramificação (“Git - Documentation,” n.d.).

O Git permite e incentiva o utilizador a criar vários ramos locais que podem ser totalmente independente uns dos outros tal como se pode visualizar na Figura 5.

16

Figura 5 - Funcionamento básico do controlo de versões Git.

É aconselhado ter um ramo que contenha sempre e apenas o que vai para a produção - branch Master - bem como um outro - branch Develop - reservado aos testes do trabalho desenvolvido. São criados vários outros pequenos ramos para o desenvolvimento do dia-a-dia sendo estes representados na Figura 5 pelos branches Front-end, Back-end, Header e Footer. Depois da criação de ramos em que são trabalhados recursos independentes tais como o header ou o footer, é aconselhado apagar esses mesmos ramos logo após o trabalho desenvolvido ser enviado para o ramo principal de desenvolvimento, o branch Develop (“Git - Documentation,” n.d.).

2.2. Responsive Web Design

A internet, cujo o acesso se tem vindo a massificar ao longo dos anos, é já considerada um serviço público essencial em muitos países a nível mundial. Com a sua popularização, desenvolveram-se também vários dispositivos de acesso desde computadores fixos, portáteis, tablets, telemóveis, entre outros, o que levou ao surgimento de novos desafios em termos de visualização da informação, essencialmente, devido aos aspetos - como o tamanho e a densidade por pixel (DPI) - que definem cada tipo de ecrã.

Em 2010, com vista à resposta aos desafios inerentes à uniformização da visualização da informação em diferentes dispositivos, Ethan Marcotte propôs a o

17

modelo Responsive Web Design (RWD) que sugere que o design e desenvolvimento devem responder ao comportamento do utilizador e do ambiente com base no tamanho de ecrã, plataforma e orientação (Marcotte, 2010). A essência do RWD é projetar um mecanismo de exibição de conteúdo da web num design perfeito para qualquer dispositivo e assim permitir aos utilizadores uma melhor experiencia de uso e acesso a todas as informações que pretende o mais rapidamente possível e com o mínimo de esforço em qualquer dispositivo (Baturay & Birtane, 2013).

O RWD consiste em três principais recursos técnicos que devem ser seguidos:

 Media Queries e resolução de ecrã: São um módulo CSS3 que permitem definir os estilos CSS de acordo com as características do tamanho de ecrã. Usando algumas linhas de código, pode-se alterar o conteúdo da página exibida de acordo com a largura do ecrã, orientação do dispositivo (paisagem ou retrato) entre outros recursos (Jiang, Zhang, Zhou, Jiang, & Zhang, 2014). Pode ser visualizado na Figura 6 um exemplo simples de como usar as Media Queries. Neste caso definiu-se na classe footer que até um tamanho de ecrã de 935 pixéis o tamanho de letra é de 12 pixéis. Com o intuito de restringir o tamanho de letra em ecrãs de smartphones, neste exemplo, define-se 10 pixéis para a propriedade

font-size num tipo de ecrã cuja largura máxima é de 425 pixéis.

Figura 6 - Exemplo de uso de Media Queries.

 Estrutura de grelhas fluídas: O RWD funciona em múltiplos dispositivos usando grelhas fluídas. Permitem que o conteúdo seja redimensionado e

18

organizado à medida que a largura, baseada em percentagem, de uma página web se expande ou diminui como no exemplo da Figura 7.

Figura 7 - Disposição do mesmo conteúdo em diferentes dispositivos Fonte: www.civilspot.com.

 Imagens e conteúdo multimédia flexíveis: As imagens devem ser flexíveis e se ajustar proporcionalmente ao espaço onde estão inseridas. Com o uso de HTML5 e CSS3, vídeos e conteúdos áudio também devem seguir o mesmo comportamento das imagens.

Seguindo os pontos anteriores e com as recentes atualizações dos browsers é necessário realçar as principais vantagens do RWD:

 Tanto os designers com os programadores front-end poupam tempo na implementação e manutenção das páginas criadas.

 O utilizador não necessita de usar zoom nas páginas ao usar dispositivos móveis, tornando a navegação mais agradável, fluída e acessível.

 A maioria dos web browsers é compatível com os diferentes métodos de RWD, sendo uma mais valia na otimização para os motores de busca. Usando a ferramenta “inspecionar elemento”, ao clicar no botão direito do rato, contida nos browsers é possível testar o quão responsiva é a página web que se está a desenvolver.

19

2.3. Search Engine Optimization (SEO)

SEO, tal como o nome indica foca-se, em otimizar qualquer página web para aparecer nos melhores lugares dos motores de busca tais como Google Chrome, Mozilla Firefox, Microsoft Edge, entre outros. Como 93% do tráfego da Internet é gerido por mecanismos de busca, explorar o potencial dos motores de busca é crucial (Egri & Bayrak, 2014).

O SEO está diretamente relacionado com a taxa de visitas de uma página web, uma vez que o número crescente de websites produzem uma grande concorrência em termos de classificação nos motores de busca. Os utilizadores usam a pesquisa dos motores de busca para alcançar o destino desejado e verificam os resultados da pesquisa para encontrar as páginas pretendidas. Portanto, os motores de busca são as ferramentas mais importantes que desempenham um papel significativo para os websites chegarem ao utilizador. É necessário ter em consideração que o SEO está em constante evolução pois os algoritmos de otimização mudam frequentemente consoante os hábitos de pesquisa dos utilizadores (Marques, n.d.).

Um dos principais aspetos a ter em conta em SEO é o tempo que demora a abrir um

website, ou seja, o desenvolvimento front-end do website tem que ser construído com

certas normas de SEO para cumprir esse requisito primordial e se diferenciar face à concorrência. Para tal, as imagens devem ser comprimidas para tamanhos menores e com a menor perda de qualidade possível, assim como ficheiros CSS e JS dos quais se devem suprimir comentários e espaços. O tempo em que o utilizador permanece numa página web também é um indicador de satisfação. De acordo com o Google, existe uma relação entre o tempo de permanência numa página web e a qualidade e funcionalidade da mesma. A tag <title> no HTML é um dos elementos mais relevantes para o motor de busca do Google, uma vez que é, precisamente, o título que é considerado para exibição nos resultados das pesquisas. Por este motivo, é também de grande importância oferecer um título sugestivo à página, para que o utilizador saiba o que esperar da mesma.

Outro aspeto importante em SEO é tornar os endereços de uma página web amigáveis, isso porque o Google lê o endereço para saber do que se trata a página antes mesmo de ler o documento. No caso da nomenclatura das imagens, “nome-do-produto.jpg” é o recomendável e não “prod001.jpg”. Nas imagens também é recomendável usar o atributo ALT que especifica um texto alternativo na imagem caso

20

a imagem não seja exibida, informando assim os motores de busca sobre o significado da imagem (Marques, n.d.).

Por fim, o aspeto essencial para boas normas de desenvolvimento front-end com SEO é tornar o website ou página web responsivos. Não se pode criar um website pensando somente em seu funcionamento num só tipo de tamanho de ecrã. Ter um website acessível em todas as plataformas é muito importante, pois os acessos em dispositivos móveis são cada vez maiores (Marques, n.d.). Isto é um dos fatores que conta bastante para o Google indexar o website.

2.4. Frameworks de desenvolvimento front-end

Construir uma página ou aplicação web de raiz pode levar muito tempo de desenvolvimento e elevados custos. Uma framework de desenvolvimento front-end é usada por programadores e designers como uma ferramenta para acelerar o processo de desenvolvimento de um projeto. Desta forma, não é necessário iniciar um projeto de raiz mas sim ter uma base sólida para um desenvolvimento. Uma framework de desenvolvimento front-end é basicamente constituída pelos seguintes elementos:

 Código HTML que auxilia a composição da estrutura das páginas web;

 Conjunto de classes CSS e CSS3 pré definidas para alterações visuais e gráficas;

 JavaScript para alterar elementos dinâmicos tal como menus laterais, menus para dispositivos móveis entre outros;

 Correções de compatibilidade entre browsers web;

 Media Queries predefinidas;

As frameworks mais populares e usadas são o Bootstrap e a Foundation sendo que a primeira acaba por se evidenciar nestes parâmetros, como pode ser visualizado na Figura 8 em que se apresenta a procura das respetivas versões mais usadas. (Jackson, 2016). Estes valores foram obtidos através da ferramenta Google Trends, entre o dia 01 de Janeiro de 2016 a 01 de Fevereiro de 2017.

21

Figura 8 - Nível de procura das duas versões mais usadas do Bootstrap e Foundation com base no Google Trends.

O uso deframeworks de desenvolvimento front-end inclui inúmeras vantagens, tais

como as que serão apresentadas em seguida:

 Aceleram o desenvolvimento de um projeto;

 Permitem organizar código, o que facilita a edição do mesmo;

 A maioria são opensource;

 São regularmente atualizadas com correções de bugs e novos recursos;

 Incluem Media Queries e compatibilidade com os diferentes browsers;

No entanto também possuem algumas desvantagens , entre as quais:

 As constantes atualizações exigem uma consulta recorrente e extensiva da documentação inerente a novas versões;

 Implementação de código supérfluo para situações em que os projetos sejam de pequena escala;

 Faltando um recurso que não esteja incluído, será necessário incorporar recursos externos, garantindo a compatibilidade dos mesmos;

Em seguida, serão apresentadas as principais características da terceira versão do Bootstrap e da sexta versão do Foundation.

22

2.4.1.

Bootstrap

O Bootstrap foi criado em 2011 por Mark Otto e Jacob Thornton como uma solução interna do Twitter para resolver as inconsistências de código no seio da equipa de desenvolvimento. A finalidade original do Bootstrap era incentivar o uso de uma única estrutura de código e nomenclatura de classes pelas equipas de desenvolvimento. A ideia resultou em menos inconsistências de código e consequentemente uma maior eficiência e um menor tempo de desenvolvimento das tarefas (Silva, 2014).

Para um aproveitamento vantajoso do Bootstrap, é recomendado interligá-lo à biblioteca jQuery, sendo esta uma biblioteca do JavaScript (Albino, Morgado, Morais, & Junior, 2015).

O Bootstrap é baseado num sistema de grelha dividido em 12 colunas que podem agrupar-se consoante a necessidade do desenvolvimento de uma página web. Tal como o exemplo apresentado na Figura 9, é possível juntar 8 colunas numa só para formar uma única coluna maior e ao lado dessa ter outro conjunto de 4 colunas agrupadas, somando assim, as 12 colunas da grelha. Isso possibilita a criação de grelhas personalizadas e adaptáveis às necessidades de qualquer projeto.

Figura 9 - Sistema de grelhas do Bootstrap Fonte: http://getbootstrap.com/css/.

Recorrendo ao uso de Media Queries do Bootstrap, é possível fazer com que as colunas se adaptem à largura de qualquer dispositivo de visualização. A largura de ecrã é determinada através de quatro tipos:

 Dispositivos muito pequenos (Extra small devices): O conteúdo adapta-se quando a largura é inferior a 768 pixéis. Neste caso é usada a classe

23  Dispositivos pequenos (Small devices): o conteúdo adapta-se quando a

largura é superior a 768 pixéis e inferior a 992 pixéis. Neste caso é usada a classe “.col-sm-”.

 Dispositivos médios (Medium devices): o conteúdo adapta-se quando a largura é superior a 992 pixéis e inferior a 1200 pixéis. Neste caso é usada a classe “.col-md-”.

 Dispositivos grandes (Large devices): o conteúdo adapta-se quando a largura é superior a 1200 pixéis. Neste caso é usada a classe “.col-lg-”.

Os espaços entre cada coluna possuem, por defeito, 30 pixéis. Realça-se que as colunas têm que ser criadas dentro de um contentor chamado pela classe “.container” que já possui o estilos predefinidos de um contentor Bootstrap (Albino, Morgado, Morais, & Junior, 2015). Para uma melhor compreensão do funcionamento da grelha é possível visualizar, na Figura 10, as adaptações das colunas consoante o tamanho de cada dispositivo.

Figura 10 - Sistema de grelha do Bootstrap representado em cada tipo de dispositivo. Fonte:

http://www.tutorialrepublic.com/twitter-bootstrap-tutorial/bootstrap-grid-system.php.

Além do sistema de grelhas o Bootstrap fornece uma alta gama de componentes predefinidos, disponíveis na sua documentação, tais comos: barras de navegação, botões, alertas, barras de progresso, dispositivos de transição de imagens entre muitos outros. Fornece igualmente uma biblioteca de ícones designada de Glyphicons (Silva, 2014).

24

2.4.2.

Foundation

O Foundation foi criado em 2008 pela equipa de desenvolvimento da ZURB para servir de guia de estilo e para um desenvolvimento rápido dos projetos da empresa. Esse mesmo guia e em conjunto a pluguins jQuery tornaram-se a primeira versão do Foundation, lançada em 2011.

O Foundation oferece uma vasta gama de personalizações onde é possível escolher diretamente o numero de colunas que os elementos do projeto terão e, ainda, que tipo de componentes como por exemplo botões, barras de navegação, tal como pode ser visto na Figura 11. Também permite personalizar os principais elementos, como textos de alertas e do cabeçalho, entre outros - para definir o aspeto dos recursos do projeto. (Silva, 2014).

25

Figura 11 - Página de personalização da base de um projeto em Foundation Fonte:

http://foundation.zurb.com/sites/download.html/.

Segundo Silva (2014), o Foundation tem uma abordagem onde o design é projetado pelo utilizador, sendo uma vantagem para as equipas de desenvolvimento, já que permite uma maior personalização dos projetos e quebra a tendência das práticas realizadas em outras frameworks cuja utilização no desenvolvimento acaba por resultar em projetos de aspeto bastante semelhante, em termos de design.

26

O Foundation fornece igualmente várias bases em HTML para diversos tipos de projetos desde páginas de produtos, portefólios, blogs entre outros como pode ser visto na Figura 12.

Figura 12 - Bases de projetos em HTML fornecidas pelo Foudation Fonte:

http://foundation.zurb.com/templates.html.

2.4.3.

Comparação entre o Bootstrap o Foundation

O Bootstrap é bastante popular, visto que, com uma leve pesquisa é fácil de encontrar bases em HTML já feitas, plugins e componentes CSS e JS a serem usados. Apesar da aparente popularidade, são apontadas críticas às extensas e pouco intuitivas nomenclaturas dadas às classes CSS e devido ao grande número de elementos UI pré-estilizados, tais como botões, listas e menus existentes no Bootstrap, o que faz com que os projetos feitos em Bootstrap tendam a seguir um estereotipo. É mais exigente que o

27

Foundation em termos de aprendizagem, mas oferece um bom suporte de documentação e vários exemplos, disponibilizados através do website oficial (Silva, 2014).

O Foundation possui uma abordagem que incentiva o programador a criar o seu próprio design, daí não oferecer tantos elementos UI comparado ao Bootstrap. Esse aspeto é visto pelos programados como uma mais-valia, visto que permite uma maior personalização dos projetos evitando assim que os mesmos se assemelhem em demasia. (Silva, 2014). O Foundation também permite que qualquer elemento presente numa coluna seja reordenado consoante o tamanho de ecrã de qualquer dispositivo. Por exemplo, num telemóvel, um tipo de conteúdo marcado como importante pode ser visualizado no início da página retirando a necessidade de ter que andar para baixo para visualizar o mesmo (Silva, 2014).

O Foundation possibilita que o programador invista mais tempo de desenvolvimento na personalização do projeto. Por ter menos elementos que o Bootrstrap, é consequentemente mais leve e tem curva de aprendizagem menor. No entanto, não deixa de ser uma opção completa. Assim como o Bootstrap, também fornece uma alargada documentação. É também a única, das duas frameworks que oferece tutoriais no seu website (Silva, 2014).

Por fim, pode-se concluir que ambas as frameworks auxiliam o desenvolvimento de projetos web. Sendo assim, é necessário ter em conta a complexidade e o tamanho de cada projeto e as vantagens de cada uma, antes de se proceder à escolha de uma delas. Deve ainda considerar-se que, mediante o tipo de projeto, poderá ser mais vantajoso usar RWD sem qualquer tipo de framework.

2.5. Content Management System (CMS)

No passado, a solução mais usada para construir uma página web ou loja online era implementá-las de raiz, o que no geral se tornava bastante dispendioso em termos de tempo e custos. Nos dias de hoje, uma solução prática que passa por desenvolver uma página web ou loja online a partir de um Content Management System (CMS) que permite gerir os conteúdos da página web de forma dinâmica, numa área reservada para esse efeito, sem ter a necessidade de ir ao código fonte da página mudar os conteúdos.

28

Existem diversos CMS opensource o que permitem partir de uma base e construir e personalizar como o pretendido com vantagens em termos de recursos temporais e financeiros. Alguns dos mais reconhecidos CMS incluem o Wordpress, Joomla, Magento e Drupal (Marques, n.d.). O Wordpress é o mais usado por todo o mundo devido à sua simplicidade e curta curva de aprendizagem (Marques, n.d.). O Wordpress oferece igualmente uma grande quantidade de plugins, e um vasto suporte documental que pode ser facilmente encontrado devido à grande comunidade que o usa. Para se ter uma noção do uso do Wordpress, existem mais de 55 milhões de blogs contruídos em com este CMS. Para além disso, estima-se que, 337 milhões de utilizadores visualizem mais de 2,5 mil milhões de páginas mensalmente e que sejam feitas 500 mil novas publicações diárias, gerando 400 mil comentários. Isto tudo apenas em páginas web alojadas no WordPress.com, fora as que estão em alojamentos próprios (Marques, n.d.).

2.5.1.

Umbraco

O Umbraco é um CMS responsive, em constante evolução e com um uso cada vez maior. É desenvolvido em .NET (Microsoft) e é, ainda, flexível e opensource. Permite ao utilizador criar, editar e publicar conteúdos autonomamente e de forma organizada como exemplificado na Figura 13. Nos dias de hoje, estima-se que mais de 250 mil

websites no mundo tenham sido construídos em Umbraco (Correia, 2017).

O Umbraco oferece altos níveis de performance na construção de websites, devido à facilidade de personalização e edição dos seus projetos, tanto para os programadores como para os designers e, igualmente, devido à facilidade de gestão para os utilizadores e a capacidade de organizar grandes quantidades de conteúdos (Correia, 2017). Tudo numa base bastante sólida que separa claramente o back-office e o front-end, através da arquitetura model-view-controler (MVC). A arquitetura MVC é um padrão na arquitetura de software. Os dados (Model) são separados do layout (View). Assim, as modificações de layout não afetam a manipulação dos dados, e estes poderão ser reestruturados sem mudar o layout (Barbosa et al., 2017).

29

Figura 13 - Back-office do Umbraco do projeto Medical Design realizado pela PontoPR Fonte:

http://www.medicaldesign.pt/.

Comparado a outros CMS, uma das grandes mais-valias do Umbraco é ser um CMS que não gera código próprio para o front-end. Isto permite que, em termos de desenvolvimento front-end, seja possível implementar layouts com boa interação e experiência do ponto de vista do utilizador, sem que a plataforma de gestão de conteúdos seja um entrave (Correia, 2017).

2.5.2.

NopCommerce

O NopCommerce é um CMS responsive e opensource, destinado ao comércio eletrónico, que inclui uma área reservada à loja contendo páginas de produtos, categorias, subcategorias e tópicos, bem como as páginas do carrinho de compras, lista de desejos e de checkout. Possui igualmente uma área de administração, exemplificada na Figura 14, permitindo ao administrador, gerir todos os aspetos da loja. Isso inclui criar categorias, adicionar, gerir e criar produtos, editar páginas de tópicos, entre outros aspetos. É igualmente possível gerir opções de envio, configurações de impostos e métodos de pagamento (Atkinson, 2013).

30

Figura 14 - Exemplo de uma loja e da sua área Fonte: www.nopcommerce.com/demo.aspx.

Existem aproximadamente mais de 27.000 lojas construídas em NopCommerce. A sua documentação é igualmente vasta e abrange o uso da loja e a parte administrativa, para programadores e designers na construção e personalização das lojas (“nopCommerce - ASP.NET Open-source Ecommerce Shopping Cart Solution,” n.d.). A comunidade de utilizadores em fóruns é, também, bastante alargada.

Tal como no Umbraco, o NopCommerce possui uma arquitetura MVC onde o

back-office está separado do front-end, o que facilita o desenvolvimento e manutenção de

código para os programadores e designers. Fornece ainda, forma de criar e implementar

plugins externos, personalizando-os de acordo com as necessidades de cada projeto.

Permite, também, criar novos temas que se podem personalizar conforme as necessidades de quem desenvolve.

Por fim conclui-se que o NopCommerce é um CMS que pode ser perfeitamente considerado para a criação de lojas online personalizáveis tanto a nível de aspeto como de estrutura. Um exemplo disso é a loja http://www.custamenos.com criada pela PontoPR onde usando o tema base do NopCommerce, foi possível criar uma loja personalizada e intuitiva para os clientes.

No capítulo seguinte, serão apresentados todos os projetos desenvolvidos, no qual se enquadram os requisitos relativos a cada um, bem como o planeamento, implementação e resultados. Para além das imagens inerentes ao layout final de cada projeto, também os endereços web são fornecidos para consulta online.

32

3. Projetos

Neste capítulo é mostrado e explicado cada projeto desenvolvido na PontoPR. Para uma melhor compreensão e leitura do capítulo, os projetos serão alinhados e identificados por ordem cronológica do desenvolvimento dos mesmos

A equipa de desenvolvimento foi constituída por três programadores back-end, dois programadores front-end (sendo um dos programadores front-end o autor deste documento), um designer gráfico, um representante comercial e um chefe de equipa.

Até ao final do ano de 2016, o planeamento das sprint na PontoPR era feito todas as segundas feiras. A nomenclatura da cada sprint correspondia ao número da semana do ano mais o diminutivo do ano, por exemplo, 46-16 corresponde à sprint semana 46 do ano de 2016. A partir da primeira semana de 2017, as sprint começaram a ser planeadas de duas em duas semanas. A título de exemplo, a nomenclatura 03-17 corresponde à terceira sprint de 2017 que, por sua vez, diz respeito à sexta semana.

3.1. Landing Page 906.pt

A 906.pt é uma loja de instrumentos e formação musical, arte, artesanato e brindes, sediada na cidade de Amarante. A loja pretende ter uma presença online com um site institucional e loja. Para tal foi necessário criar uma landing page para anunciar a vinda do website. O projeto foi iniciado dia 19 de Outubro de 2016 e concluído a 21 de Outubro de 2016 no decorrer da sprint 42-16 e realizado localmente sem recurso a controlo de versões.

Para a conceção do front-end da landing page foi criada uma nova tarefa no Backlog da sprint 42-16 com o anexo da maquete do aspeto pretendido, tal como na Figura 15 e com a condição de que o desenvolvimento deveria ser feito em Bootstrap com uma transição das imagens de fundo.

33

Figura 15 - Maquete da landing page 906.pt.

Depois de analisar a maquete um dos desafios de desenvolvimento da da landing

page foi a implementação da transição das imagens de fundo de forma automática. Para

tal, foi usada a propriedade CSS3 Animation e os seus parâmetros para definir o tempo e opacidade da transição entre cada imagem. A vantagem dessa propriedade é ela permitir que a imagem também se adapte à largura de ecrã tal como o resto dos elementos da landing page e sobretudo, retirar, a necessidade de se invocar um slider externo e pré-feito, o que não se justificava neste trabalho. Com o uso do Bootstrap e das suas grelhas divididas em 12 colunas foi possível ajustar o formulário de contacto com a informação de contacto. Pode ser visualizado na Figura 16o resultado final.

34

Figura 16 – Resultado final da implementação da landing page. Fonte: www.906.pt

.

3.2. Website da Leitaria da Quinta do Paço

A Leitaria da Quinta do paço é uma cadeia de cafetarias e pastelarias espalhadas pelo Porto e Lisboa que iniciou a atividade em 1920 com a produção de leite, manteiga, queijo e chantili. Nessa época afirmou-se como a primeira empresa do setor a distribuir leite pasteurizado em garrafas de vidro, numa altura em que a distribuição era feita em bilhas que as vendedoras do Porto transportavam na cabeça. Ano após ano foi ganhando fama e impondo a qualidade dos seus produtos que se mantém até hoje. A manteiga com sal vendida ao peso, na embalagem de papel vegetal - continua a ser um clássico - bem como os queijos e o chantili, que, aliás, depressa ganhou uma fama sem precedentes. Vendido ao balcão, em saquinhos de papel encerado, protagonizou nos anos cinquenta aquilo que viria a ser a imagem da marca: éclair com cobertura de chocolate.

Atualmente, a Leitaria da Quinta do Paço conhece uma nova fase de revitalização e expansão. Além da loja inicial, na Baixa do Porto, nasceram novos locais onde se podem encontrar os excelentes produtos da Leitaria: Mercado do Bom Sucesso,

35

NorteShopping, Matosinhos e Lisboa. Visando expandir a sua presença na web, a empresa solicitou à PontoPR a construção de um website informativo acessível através de qualquer dispositivo.

O website foi construído na plataforma Umbraco com uso do Bootstrap ao nível de

front-end. Um dos desafios apresentados na reunião de planeamento da sprint 45-16 do

dia 07 de Novembro de 2016 foi a implementação de um módulo de imprensa no

website. Os requisitos principais do módulo teriam que permitir ao utilizador visualizar,

num slider de imagens, várias fotografias relativas a notícias de imprensa sobre a Leitaria da Quinta do Paço. Esse mesmo slider teria que se adaptar a qualquer largura de ecrã. Foi então decidido na reunião que seria usado o Bootstrap Carousel como meio para apresentar as imagens. A escolha deveu-se ao facto do Bootstrap Carousel ser um

plugin que já vem integrado no Bootstrap o que retira a necessidade de chamar um

recurso externo. Ao vir integrado no Bootstrap, a adaptação ao ecrã ocorre automaticamente.

Depois de chamar o Bootstrap Carousel foi necessário adaptar o aspeto do mesmo ao resto do website, mudando os seus estilos CSS. Para realizar a implementação, recorreu-se ao controlo de versões GIT e criou-se um ramo chamado frontendPress destinado exclusivamente ao módulo de imprensa. O resultado pode ser visualizado na Figura 17.

Figura 17 – Resultado final da implementação do módulo de Imprensa com uso do Bootstrap Carousel. Fonte:

http://www.leitariadaquintadopaco.com/imprensa/2016/.

Foram igualmente corrigidos certos aspetos no resto do website da Leitaria, tais como o espaçamento entre o logótipo sobre o slider da página principal, o alinhamento dos menus presentes no rodapé e, por fim, o tamanho das imagens representantes dos produtos de leitaria. O tamanho foi definido para 230 pixéis isto porque caso não fosse