II - estudogeral.sib.uc.pt · Histórico de Coimbra (gravações de Luís Antero), sobre o Google...

II

Aos meus pAis, irmãos, primos e fAlecidA Avó. A Cátia Roça e à malta dos casamentos, em especial aos que acompanharam mais ativamente este projeto – (alfabéticamente) Adriana Barbosa, Adriana Nunes, Andreia Lopes, Carolina Lopes, Jéssica Parente e Joana Rua.

Tenho ainda a agradecer especialmente ao jacc – Catarina Pires e José Miguel Pereira –, aos Doutores Paulo Peixoto e Sílvia Ferreira – professores do curso de Sociologia na Faculdade de Economia da Universi-dade de Coimbra –, a Daniel Silva – aluno de mestrado do mesmo curso –, aos funcionários do Centro de Documentação 25 de Abril da Univer- sidade de Coimbra, aos funcionários do Convento de São Francisco em Coimbra, a Márcia Carvalho, a José Maria Cunha, a Diogo Ferreira, a Maria João Lamas, a Diogo Ferreira, a Tiago Martins, a Luís Antero, a João Duarte, a Ana Botelho e sua equipa, a Helder Wasterlain, a Hugo Oliveira, a Álvaro Oliveira, aos sócios do Café Santa Cruz, à equipa do Audiomack e a todos aqueles que me possa ter esquecido e que, por isso, peço desculpa.

Por fim, agradeço especialmente aos meus orientadores Pedro Martins e João Bicker, cruciais para o sucesso deste projeto.

Agradecimentos

III

Arquivo Digital do Centro Histórico de Coimbra Agradecimentos

IV

Em 2016, o Jazz ao Centro Clube (JACC) levou a cabo o Museu Temporário de Memórias, uma exposição no antigo Armazém de Fazendas, na Rua velha, onde foram recordados objetos e histórias dos comerciantes da Baixa de Coimbra – estes que são uma importante parte da história da cidade.

Esta foi a primeira iniciativa do jacc para perpetuar as memórias do Centro Histórico da cidade. Contudo, a herança da Alta e Baixa de Coimbra é muito mais do que aquilo que foi possível mostrar alí.

Resumo

V

Arquivo Digital do Centro Histórico de Coimbra

O Arquivo Digital do Centro Histórico de Coimbra (adchc) vem preservar todas estas memórias e disponibilizá-las online àqueles que as quiserem consultar. Pretende ainda fomentar a contribuição da comunidade, per-mitindo o upload de conteúdos, assim como a criação artística através dos mesmos, forne-cendo-os gratuita e dinamicamente.

Esta dissertação trata da programação back-end e front-end da plataforma/website do Arquivo Digital do Centro Histórico de Coimbra e do respetivo design de interface e interação. A par disto, trata do design da sua identidade gráfica e meios de divulgação.

Resumo

Centro Histórico de Coimbra; Arquivo; Memória; Colaboração; Criação; Website; Programação back-end e front-end;Design de interface/interação; Identidade gráfica;Instalação interativa.

VI

Back in 2016, the Jazz ao Centro Clube (jacc) came up with Museu Temporário de Memórias, an exhibition at the old Armazém de Fazendas, at Rua velha, where objects and stories from Coimbra’s downtown sellers were remembered – which are an important part of the city's history.

This was the very first initiative of jacc to perpetuate the memories of historical center of the city. However, its heritage is much more that what could be shown there.

Abstract

VII


The Digital Archive of Coimbra’s Historical Center (adchc) comes to preserve all of these memories and make them available online for those who want to consult them. It also aims to foster the community contribution by uploading contents, and encourage the artis-tic creation with the latter, providing them free and dynamically.

This dissertation is about the back-end and front-end development of the website of the Digital Archive of Coimbra’s Historical Center and the respective interface/interaction design. In addition, it is about designing its graphic identity and dissemination artifacts.

Abstract

Coimbra’s Historical Center; Archive; Memory; Collaboration; Creation; Website; Back-end and front-end Programming;Interface/interaction design; Graphic identity;Interactive installation

VIII

1. Illustris Civitatis Conimbriae Ad Flumen Mundam Effigies. A mais antiga estampa de Coimbra, de Georg Hoefnagel (publicada em 1572)

2. Conimbricae, Lusitanea Urbs Ad Mundam Aquaeductu Sebastianis Regis Celebris. Elaborada no Século xviii, de Nicolas Ten Horne (publicada em 1718)

3. Cidade De Coimbra, de Legrand (publicada em 1839)4. Elétrico em Coimbra no século xx5. Folha 16 da Planta da Cidade de Coimbra, ahmc/Planta da Cidade, 1934.6. Coimbra antes das demolições, na década de 30 do século xx7. Destruição da Alta para dar lugar aos novos colégios, no século xx8. Coimbra. Cidade universitária (vista aérea), 19799. Universidade de Coimbra – Alta e Sofia10. Mapeamento manual das zonas abrangidas pelo Arquivo Sonoro do Centro

Histórico de Coimbra (gravações de Luís Antero), sobre o Google maps11. Modelo de debug para o armário12. Performance de Luís Antero no dia de abertura da exposição Dar a Ouvir –

Paisagens Sonoras da Cidade (2017), no Convento de São Francisco13. Performance de Luís Antero acompanhada à guitarra por Pedro Mar-

tins, criando uma nova camada sonora. Exposição Dar a Ouvir – Paisagens Sonoras da Cidade (2018), no Convento de São Francisco

14. Fonte serifada (Adobe Garamond Pro) vs fonte não serifada (Helvetica Neue LT Std)

15. Legacy Serif (serifas evidenciadas por círculos) vs Legacy Sans (sem serifas)16. Fonte não serifada (Arial) e serifada (Georgia) com 12pts ampliado17. Fonte não serifada (Arial) e serifada (Georgia) com 50pts, sem ampliação18. Layout desktop vs layout mobile19. Demonstração da adaptação de vários elementos de uma página web

a diferentes tamanhos de ecrã, devido ao uso de percentagens para definir dimensões

20. Sequência ilustrativa do antes (1) e depois (2) de carregar no botão “menu” na aplicação Gmail, no sistema operativo Android.

21. 3 imagens otimizadas para 3 dispositivos diferentes, de Egor Pasko22. Timeline de carregamento do Git-Tower, no Chrome Developer Tools

Lista de figuras

IX

Arquivo Digital do Centro Histórico de Coimbra I. Lista de figuras

23. jpeg baseline (1) vs jpeg progressivo (2)24. (1) jpeg 2600×3400 pixels num ecrã 214×280 pixels, 685K; (2) gif;

(3) jpeg 214×280 pixels 16K; (4) jpeg 428×560 pixels num ecrã 214×280 pixels, 33K

25. Demonstração de compressão de imagem por Daan Jobsis26. Página inicial de Porto Sonoro.27. Página inicial do Porto Sonoro – links mostrados quando o rato está em

cima de uma das imagens (a imagem a vermelho)28. Página “Cartografía sonora” do Porto Sonoro29. Página “Missão” do Porto Sonoro30. Página “Transformações Sonoras -> Percursos Sonoros -> Rui Penha”

do Porto Sonoro31. Página inicial do Phonambient 32. Sequência ilustrativa de se como visualizar um grupo de sons33. Formulário para pesquisa escrita do Phonambient34. Sound Player do Phonambient35. Página “Percursos Sonoros imaginários” do Phonambient 36. Página inicial da Macaulay Library 37. Módulo “Total Media”, na página inicial da Macaulay Library.38. Galerias de conteúdos na Macaulay Library (1 - Fotografias; 2 - vídeos;

3 - Sons)39. Sound player e respetiva visualização do espetro sonoro na Macaulay Library40. Página inicial (1) e página “Álbums” (2) da Biblioteca de Arte da Funda-

ção Calouste Gulbenkian no Flickr41. Imagem de perfil da Biblioteca de Arte da Fundação Calouste Gulbenkian

no Flickr42. Página inicial do MatrizPix43. Galeria de imagens e página de visualização detalhada de uma imagem

do MatrizPix44. Modelo de cascata do desenvolvimento prático do adchc.45. Diagrama de planificação do projeto46. Diagrama de planificação do projeto, comparando o tempo previsto

e o tempo real para elaboração das tarefas

X

47. The Performing Archive: Restricted Access is available for exhibitions.48. Arquivos do Amon Carter Museum49. 99 caixas e 55 mil diapositivos a cores da coleção John F.Bjorklund.

Cada diapositivo tem informações e imagens dos Estados Unidos e Canadá, de 1960 a 2000

50. Tate Photographic Archive (Paul Mellon Centre)51. Performance de Pedro Martins e Luís Antero com o ms (Mobiliário Sonoro)

01 – uma instalação interativa que permite consultar alguns conteúdos audiovisuais do adchc abrindo gavetas

52. Documentos arquivados em gaveta53. Coleção de slides no arquivo Hamburger Kunst uhh, rrz/mcc, Mentz,

(Archive of Art em Hamburgo)54. Documentos ordenados por ordem alfabética55. 100 capas de jornais do dia 12 de Setembro de 2001, por Hans-Peter

Feldmann56. José Maçãs de Carvalho, "Arquivo e Melancolia", still video, hd, cor,

som, 2016. © José Maçãs de Carvalho57. Logótipo/menu dinâmico para seleção do tipo arquivo: (1) “aberto”

(2) “fechado”58. Imagem ilustrativa do tipo de letra Fuga, desenvolvido por Diogo Ferrei-

ra no âmbito da disciplina de Tipografia Avançada da Licenciatura em Design e Multimédia na Universidade de Coimbra, orientada por Artur Rebelo: (1) Antes das reestruturações (2) Depois das reestruturações

59. Maquete do formulário para recolher a caligrafia dos utilizadores60. Maquetes do logótipo com a caligrafia dos utilizadores61. Primeiras maquetes de como o logótipo e a caligrafia dos utilizadores

poderia funcionar em cartazes62. Comparação da fonte Fuga (1) vs fonte Bungee Regular (2) aplicadas

à interface63. Bungee Regular aplicada ao título. Open Sans aplicada ao corpo de texto64. Botão de submissão (em cima) vs botão normal (em baixo)65. Mapa visível sob menu lateral graças à transparência deste último66. Maquete da página inicial, com dicas de utilização67. 6 marcadores no mapa – 5 de publicações aprovadas, 1 de uma

publicação por aprovar68. Rato sobre um marcador do mapa69. Marcador no mapa cujo publicação está aberta (foi clicado)70. Janela de pré-visualização

I. Lista de figuras

XI


71. Dois marcadores sobre a vista geométrica do mapa72. Dois marcadores sobre a vista de satélite do mapa: (1) Menos zoom

(2) Mais zoom73. Delimitação do chc através de um contorno vermelho e fundo cinza:

(1) vista geométrica (2) vista de satélite74. Exemplo da evolução da delimitação do Centro Histórico (meramente

explicativo): (1) Antes (2) Depois75. Exemplos de dois grafismos diferentes aplicados ao mapa (montagens

digitais meramente explicativas). As imagens usadas foram retiradas de idrawmaps.com/2018/4/12/compass-1 (Nate Padavick) e andreletria.pt/portfolio/elvas (André Letria) (1 e 2, respetivamente)

76. Logótipo/menu apenas com o tipo de arquivo audiográfico selecionado: (1) Aberto (2) Fechado

77. Cronologia de desseleção do tipo de arquivo bibliográfico: (1) Logótipo/menu fechado com todos os tipos de arquivo selecionados (2) Logótipo/menu aberto com o rato sobre o tipo de arquivo bibliográfico, ainda selecionado (3) Logótipo/menu aberto com o rato sobre o tipo de arquivo bibliográfico, depois de desselecionado (4) Logótipo/menu fechado, com todos os tipos de arquivo selecionados exceto o tipo bibliográfico.

78. Logótipo/menu com o tipo de arquivo audiográfico selecionado e restantes tipos de arquivo em estado intermédio de seleção (não implementado)

79. Delimitador “até” da timeline (1) Estado normal (2) com “rato sobre” (3) Digitando o dia

80. Timeline visualizando o período de 01/12/2011 a 09/08/1881. Marcador da timeline em estado normal82. Marcadores da timeline em estado “rato sobre” (acionado colocando

o rato sobre o respetivo marcador do mapa): (1) Publicações referente um dia apenas (2) Publicação referente a ao período de um mês

83. Marcador da timeline em estado “clicado” (publicação aberta)84. Maquete do método de expansão dos marcadores sobrepostos na timeline

(1 grupo expandido via “rato sobre”)85. Maquete do método de expansão dos marcadores sobrepostos na timeline

(todos os grupos (dois) expandidos)86. Marcadores no mapa: (1) Agrupados (menos zoom no mapa)

(2) Não agrupados (mais zoom no mapa)87. Menu de definições do mapa: (1) Fechado (2) Aberto88. Maquete do método de expansão de marcadores perfeitamente

sobrepostos no mapa

XII

I. Lista de figuras

89. Pré-visualização e visualização de uma fotografia de João Duarte: (1) Janela de pré-visualização (2) Janela de visualização

90. Janela de visualização posicionada na metade direita da janela principal91. Cabeçalho de pré-visualização e visualização de uma fotografia de João

Duarte: (1) Cabeçalho de pré-visualização (2) Cabeçalho de visualização e uma etiqueta nativa explicitando a consequência do clique (ativada colocando e mantendo o rato sobre o cabeçalho)

92. Janela pop-up com informação detalhada sobre a publicação93. Cabeçalho sem número identificador (mostrado aos utilizadores comuns)94. Cronologia exemplificativa da navegação na janela de visualização

de documentos (scroll): (1): Texto seguido de imagem (parcialmente visível); (2) Imagem (totalmente visível depois de fazer scroll)

95. Rato sobre imagem (imagem sem filtro e uma etiqueta nativa, dando a entender qual será a consequência do clique).

96. Janela de visualização na metade direita da janela principal; Botão “Ver publicação completa” substituindo os documentos cujo tipo de arquivo não está selecionado (neste caso o tipo de arquivo fotográfico); Botão “Eliminar publicação” imediatamente por baixo.

97. Janela pop-up nativa para confirmação o eliminar de uma publicação98. Ícone de download por Google. Retirado de iconfinder.com/icons/326639/

download_file_icon99. Ícone de download, legenda e etiqueta nativa mostrando a descrição com-

pleta de um campo (ativada colocando e mantendo o rato sobre os campos)100. Janela pop-up nativa com informação sobre um documento, ativada

clicando na respetiva legenda101. Etiqueta nativa explicativa do tipo de licença, ativada colocando

e mantendo o rato sobre o respetivo ícone102. Página web Creative Commons oficial, explicativa do tipo

de licenta cc by-nc 4.0: creativecommons.org/licenses/by-nc/4.0 103. Três publicações conectadas numa coleção (publicação do meio, aberta)

pela linha vermelha. As restantes publicações, a cinza, foram desativadas 104. Método de ativação e desativação da visualização de coleções:

(1) Coleção ativada (predefinição); (2) Coleção desativada 105. Menus laterais (lado direito da janela principal): (1) Todos os menus

no seu estado pré-definido (2) Rato sobre a etiqueta do menu “perfil”106. Menu lateral “perfil” aberto, ocupando a metade direita da janela107. Marcador (vermelho, redondo) para seleção de uma localização e raio

de procura no mapa

XIII


108. Menu lateral “procurar” aberto: (1) Sem sessão iniciada, com cam-pos escondidos (predefinição); (2) Com sessão iniciada, com campos escondidos; (3) Com sessão iniciada, sem campos escondidos

109. Menu lateral “lista” aberto: (1) Publicações organizadas por coleção (2) Publicações organizadas por ano de produção; rato sobre uma publicação e respetiva pré-visualização

110. Menu “publicar” aberto: (1) vista predefinida: rato sobre botão para redigir texto (2) Formulário para documento de texto, aberto ao carregar no mesmo botão (3) Rato sobre botão para carregar fichei-ro (4) Janela pop-up nativa para selecionar um ficheiro do dispositivo, aberta ao carregar no mesmo botão (5) Carregar um ficheiro através de arrastamento (alternativa a clicar no botão “Carregar ficheiro” (6) Formulário para documento Imagem, aberto ao selecionar um ficheiro na janela pop-up; pré-visualização da imagem selecionada (7) O mesmo formulário e os botões para submissão da publicação (“Enviar para aprovação”) e repor todos os campos em branco (“Repor todos os campos”); (8) Janela pop-up nativa pedindo confirmação para a submissão da publicação

111. Janela de visualização de uma publicação por aprovar112. Menu lateral “perfil” aberto - formulário de login113. Menu lateral “perfil” aberto - formulário de criação de perfil/conta114. Menu lateral “perfil” aberto - formulário de recuperação

de palavra-passe115. Janela pop-up nativa indicando que a sessão foi iniciada com sucesso

e qual a forma de identificar, rapidamente, que a sessão contínua iniciada116. Menu lateral “perfil” aberto - formulário de informações de perfil117. Menu lateral “perfil” aberto - formulário de alteração de palavra-passe118. Página para eliminar conta119. Palavra “exemplo” encriptada com o algoritmo sha-512120. Menu lateral “apps” aberto121. Rato sobre a hiperligação de uma aplicação no menu lateral “apps”122. Aplicação web desenvolvida com a api do adchc. Disponível em

student.dei.uc.pt/~dfl/murmur123. Menu lateral “sobre” aberto124. Janela pop-up de sugestões automáticas (implementada de raiz),

mostrando 6 sugestões125. Janela pop-up de sugestões automáticas (implementada de raiz),

mostrando que não encontrou resultados semelhantes

XIV

I. Lista de figuras

126. Janela pop-up nativa alertando para a possibilidade de publicações se-melhantes

127. Menú lateral “perfil” aberto; A etiqueta passou a mostrar “fechar” e subiu para o topo do menu

128. Janela pop-up usada para que o utilizador aguarde o completar de processos (desenvolvida de raiz)

129. Legenda de um documento áudio produzido por Luís antero: (1) a partir da resolução 8x5 (2) até à resolução 8x5

130. Aspeto visual da janela principal com resolução até 1x1: (1) logótipo/menu e timeline minificados (2) logótipo aberto

131. Aspeto visual da janela de visualização com resolução até 1x1: (1) Estado normal (2) Modo de visualização da coleção

132. Aspeto visual de uma menu lateral (“procurar”) com resolução até 1x1: (1) Estado normal (2) Modo de seleção de uma localização no mapa

133. Aspeto visual da janela principal com resolução até 5x9 (logótipo/menu em simplificação máxima)

134. Aspeto visual da janela principal com resolução até 400 pixels de altura (logótipo/menu em simplificação máxima; apenas os menus laterais “perfil” e “publicar”; campos da timeline dispostos horizontalmente)

135. Visualização do website em Chrome mobile: (1) a barra de ferra-mentas superior é mostrada por predefinição (2) barra de ferramen-tas superior escondida depois de fazer scroll (3) Calendário para escolha de data, ativado ao clicar nos campos da “timeline”

XV


136. Visualização do website em Safari mobile: (1) as barras de ferramen-tas de cima e baixo são mostradas por predefinição (2) Calendário para escolha de data na parte inferior da janela, , ativado ao clicar nos campos da “timeline”

137. Webapp do adchc: (1) Ícone no menu principal do dispositivo (2) Janela principal da Webapp (ecrã inteiro)

138. Cartaz promocional139. Página de Facebook (facebook.com/arquivodigitalchc)140. Trabalhos de preparação da instalação Murmur141. Entrada da instalação Murmur, no Convento de São Francisco142. Instalação Murmur, no Convento de São Francisco143. Resultado da mais recente auditoria Lighthouse ao website do adchc

(27 de Agosto de 2018)144. Sugestões para otimização, resultantes da mais recente auditoria

Lighthouse ao website do adchc (27 de Agosto de 2018)145. Resultado da auditoria Lighthouse a www.facebook.com (27/08/2018)146. Resultado da auditoria Lighthouse a www.youtube.com (27/08/2018)147. Resultado da auditoria Lighthouse a www.maps.google.com (27/08/2018)148. Tabela de resultados dos testes de usabilidade

XVI

□ api (Interface para programação de aplicações) refere-se a uma for-ma de aceder a informação ou serviços de software externos através de programação.

□ Adobe Flash é um programa capaz de criar animações interativas. □ Advertising é o termo inglês para referir publicidade paga. □ Avatar refere-se a uma imagem ou representação identificadora

de uma pessoa. Por exemplo, uma imagem de perfil ou de contacto. □ Back-end refere-se à parte de um programa que o utilizador não vê.

Por exemplo, armazenamento e processamento de dados, cálculos, etc. □ Brainstorming refere-se a um processo de criação de ideias e soluções,

que encoraja e assume todas as ideias possíveis como sendo boas ideias à partida e. Só depois é feito o julgamento e filtragem daquelas que são boas ou más ideias.

□ Browser, no contexto digital, refere-se a um programa do lado cliente para mostrar páginas web. Existem vários browsers como o Chrome, Internet Explorer, Edge, Firefox, Opera ou Safari.

□ css (Cascading Style Sheet) é uma linguagem para criar estilos e layout usada, normalmente, para páginas html. Atualmente esta linguagem está na terceira versão (css3).

□ Delay é o termo inglês para referir “atraso”. No contexto digital, refere-se ao tempo que uma ação demora desde que foi mandada executar, até que realmente comece a ser executada pelo sistema.

□ Desktop (topo de secretária) refere-se a um computador fixo, ou à área de trabalho de computadores pessoais em geral.

□ Developer, no contexto digital, é o termo inglês para referir uma pessoa que desenvolve software (programador).

□ Dropdown menu, no contexto digital, refere-se a um menu escondi-do que só é mostrado quando é selecionado. Normalmente, refere-se a um menu que “abre para baixo”.

□ Feedback, no contexto de interface, é um efeito ou informação resultante de uma ação.

□ Flickr é um website (rede social) para carregamento e compartilhamento de fotografia.

Glossário

XVII

Arquivo Digital do Centro Histórico de Coimbra II. Glossário

□ Frame Rate refere-se à frequência com que um frame é atualizado num vídeo, animação ou software.

□ Frame, no contexto digital (ou vídeo analógico), é uma imagem estática de um vídeo, animação ou software.

□ Front-end refere-se à parte se um programa que o utilizador vê e com a qual interage (interface).

□ Google Maps é um mapa online desenvolvido pela Google que oferece imagens de satélite, imagens de rua 360º, condições de trânsito, etc.

□ html (Hypertext Markup Language) é uma linguagem para estrutura de dados usada, normalmente, para criar páginas web. Atualmente esta linguagem está na quinta versão (html5).

□ Hack refere-se ao ato de “piratear” ou ludibriar um sistema informático. □ Input, no contexto de interface, refere-se a um método de comando ou

inserção de dados num sistema por um utilizador. □ JavaScript é uma linguagem de programação orientada a objetos, altamen-

te usada na web – lado cliente (browser) e lado servidor (node.js) –, mas também em muitos outros suportes.

□ Laptop (“topo do colo”) refere-se a um computador portátil com as capacidades de um computador fixo.

□ Layout, no contexto de design, refere-se à forma como os elementos são dispostos, por exemplo, numa página web ou folha de papel.

□ Loader, no contexto de interface, refere-se a um motivo gráfico que informa um utilizador que um processo está a decorrer.

□ Log-in, no contexto digital, refere-se a uma forma de aceder a uma conta específica numa plataforma ou base de dados, através de um identificador unívoco (email ou nome de utilizador) e uma palavra-passe.

□ Logo refere-se a um símbolo representate e identificador de uma entidade (marca, pessoa, etc.).

□ Logótipo difere de logo (símbolo de uma marca) por implicar o uso de tipografia.

XVIII

II. Glossário

□ Media query refere-se a um método (web) para verificar características do dispositivo em que um site está a ser consultado. Por exemplo, o tipo de dispositivo (ecrã, impressora, etc.) ou o tamanho do ecrã/folha.

□ Mobile, no contexto tecnológico, refere-se a dispositivos móveis, como smartphones ou tablets.

□ NoteBook (“bloco de notas”) refere-se a um computador portátil pequeno o suficiente para caber numa pasta.

□ Outdoor, no contexto de publicidade, refere-se a cartazes exteriores – – cartazes nas paragens de autocarro, painéis de publicidade nas bermas de estrada, etc.

□ Output, no contexto de interface, refere-se a um método de um sistema retornar dados ou de informar o utilizador que uma ação foi iniciada, está a decorrer ou foi terminada.

□ php (php: Hypertext Preprocessor) é uma linguagem de programação do lado servidor.

□ Parallax, no contexto digital, refere-se ao efeito de uns elementos de moverem mais rápido ou mais lentamente que outros, durante o scroll.

□ Paço Real era o local destinado aos aposentos reais. É neste espaço que encontra os locais mais emblemáticos do quotidiano da Universidade, mas também tiveram lugar aqui momentos chave da História de Portugal.

□ Performance, no contexto cultural/entretenimento, refere-se a uma apre-sentação ou exibição, normalmente com implicação de algum tipo de fisicalidade humana. No contexto digital, o termo refere-se ao desempenho de um programa ou dispositivo (rapidez, fluidez, etc.).

□ Post, no contexto naive da web social, refere-se a algo carregado/postado por um utilizador numa plataforma.

□ Rendering, no contexto digital, é o processo computacional automático para a geração de uma imagem final.

□ Responsividade, no contexto web, refere-se ao facto de um website ser capaz de se auto ajustar a qualquer tamanho de ecrã ou dispositivo.

□ Scroll, no contexto de interface, refere-se ao ato de mover uma página, horizontal ou verticalmente, para que um utilizador possa visualizar mais conteúdos.

XIX

Arquivo Digital do Centro Histórico de Coimbra II. Glossário

□ Slider, no contexto digital, refere-se a um controlo que pode ser arrastado para controlar uma variável, como o volume de uma música.

□ Slideshow é o termo inglês para designar “apresentação de dispositivos”. □ Small-caps refere-se às letras maiúsculas de uma fonte que têm a altura

x das letras minúsculas (a altura de, por exemplo, um “a” minúsculo). □ Smartphone refere-se a um telemóvel capaz de desempenhar muitas das

funções de um computador. Normalmente, tem um ecrã tátil, acesso à Internet e é capaz de descarregar e correr aplicações.

□ Sociologia refere-se à ciência que estuda a realidade social. Por exemplo, as relações e comportamentos que os indivíduos estabelecem entre si.

□ Software refere-se à parte “não física” dos computadores. Por exemplo, os programas.

□ Sound Player, no contexto digital, é um programa de software capaz de reproduzir ficheiros de som.

□ Sound visualizer, no contexto digital, é um programa de software capaz de gerar gráficos a partir da análise da amplitude ou frequência de ficheiros de som.

□ SoundCloud é um website (rede social) para carregamento e compartilha-mento de música/som.

□ Tablet refere-se a um computador portátil com um sistema operativo mobile. Tipicamente, tem um ecrã tátil.

□ Tag (etiqueta), no contexto digital, refere-se a uma palavra descritiva de um elemento. Normalmente, tags são usadas para encontrar elementos através de pesquisas.

□ Timeline (linha temporal) refere-se a uma representação gráfica de um período de tempo, onde eventos importantes são marcados.

□ Vimeo é um website (rede social) para carregamento e compartilhamento de vídeos.

□ YouTube é um website (rede social) para carregamento e compartilha-mento de vídeos.

XX

I. Lista de figurasII. Glossário01. Introdução

1. Motivação2. Objetivos3. Enquadramento4. Contribuições5. Estrutura da dissertação

02. Centro Histórico de Coimbra (chc)1. História2. Atualidade3. Arquivo Sonoro do Centro Histórico de Coimbra

03. Estado da arte 1. Arquivos2. Design de interação e interface3. Fontes web4. Design responsivo5. Performance

04. Casos de estudos05. Metodologia e planificação

Índice

XXI

Arquivo Digital do Centro Histórico de Coimbra Índice

06. Projeto1. Requisitos2. Design3. Programação4. Ferramentas de programação do lado cliente5. Desenho da interface e programação do lado cliente6. Programação do lado servidor7. Divulgação

07. Testes

1. Avaliação automática2. Testes de utilizador

08. Conclusões e perspetivas futuras

III. Bibliografia

IV. Anexos1. Lista de 25 plataformas analisadas 2. Brainstorm3. Processo de design da imagem gráfica4. Processo de design da interface

1

1. Motivaçãoem 2016, o Jazz ao Centro Clube (jAcc)1 levou a cabo o Museu Temporário de Memórias, uma exposição no antigo Armazém de Fazendas, na Rua velha, onde foram mostrados e recordados “objetos de antigos e atuais comerciantes da Baixa de Coimbra que fizeram (e alguns ainda fazem) parte da história da cidade” (Visão Se7e, 2016). Esta foi a primeira iniciativa do jacc para perpetuar as memórias do Centro Histórico da cidade. Contudo, a herança da Alta e Baixa de Coimbra é muito mais do que aquilo que foi possível mostrar alí.

O Arquivo Digital do Centro Histórico de Coimbra (adchc) é uma plataforma online construída para dar continuidade ao trabalho de preservação das memórias do Centro Histórico de Coimbra (chc) e disponibilizá-las da forma mais cómoda possível àqueles que as quiserem consultar. Este museu virtual incentiva ainda a colaboração da comunidade através do upload e download de documentos, disponibilizando-os gratuita e dinamicamente. A plataforma tor-na-se assim numa proveitosa ferramenta para estudos sociais e criação artística.

Introdução

1. O jacc – Jazz ao Centro Clube – é uma associação cultural sem fins lucrativos para a promoção da cultura, criada em 2003 e com sede em Coimbra.

2

Arquivo Digital do Centro Histórico de Coimbra 01. Introdução

“...creative responses to expressive cultural traditions play a critical role in cap-turing not only important aspects of the tradition itself, but also possesses within them important metadata of the time — information about the present moment in which the tradition occurred.” (Diana A. Chester, 2016)

Além de por todas estas mais-valias comunitárias, o projeto destaca-se por englobar várias áreas de interesse pessoal como o design de identidade, design gráfico, design e programação web e arte de instalação interativa.

3

01. Introdução

2. ObjetivosEste projeto tem como objetivo o design e conceção de um arquivo digital online – website/plataforma– capaz de albergar documentos de imagem, vídeo, som e texto sobre o chc. Os mesmos deverão poder ser carregados e consulados por qualquer utilizador. Antes de serem disponibilizados ao público, os documentos deverão ser aprovados pelos administradores da plataforma. Paralelamente, pretende-se o desenvolvimento da imagem gráfica do arquivo, assim como o pensar, desenhar e conceber de formas para a comunicar. Desta forma, este pode classificar-se um projeto transmídia, enquadrado em diversas áreas como o design, arte e tecnologia:

1. Design e desenvolvimento web (front-end e back-end) – Um trabalho cuidado de design e programação é vital para o projeto, pois este acarreta largas quantidades de dados, muitas funcionalidades e a necessidade de funcionar em vários tipos de dispositivos, com capacidades de processamento e memória diferentes;

2. Design de interface e interação – Os utilizadores alvo da plataforma vão desde crianças/adolescentes a idosos, dos pouco mais que analfabetos, até aos mais letrados. Por esta razão, é importante que a interface seja fácil e clara, e que as suas formas de interação se prendam por alguns standards culturais. Isto não descredibiliza a criação de novas formas de interação. Um utilizador deve também ser discriminado por ser um utilizador frequente ou não. Por exemplo, um novo utilizador não deve ser baralhado com um enorme leque de funções à partida. No entanto, funcionalidades mais complexas podem existir para que um utilizador experiente as possa utilizar. Tudo isto deve ser bem ponderado no processo de design de interface e interação;

4


3. Design de marca/identidade gráfica – Além de projetar e progra-mar a plataforma e a sua interface, cabe ainda nos encargos do projeto o desenvolvimento da imagem gráfica do arquivo – desenhar a marca. O requisito mínimo nesta área não é mais que um logótipo para utilização na plataforma e em cartazes promocionais. Porém, é crucial que a marca transmita confiança e irreverência, e que seja suficientemente versátil para ser usada no máximo de suportes – desde o maior outdoor até ao menor avatar na lista de contactos de um smartphone;

4. Instalação interativa – Como forma de divulgar o projeto e de demonstrar o seu potencial para a criação artística, foram criadas instalações áudio e audiovisuais interativas, que tiram partido de documentos de som e/ou imagem do arquivo.

5

01. Introdução

5. Estrutura da dissertaçãoO restante documento encontra-se estruturado da seguinte forma:

02. Centro Histórico de Coimbra

Este capítulo pretende contextualizar e perceber a importância do Centro Histórico de Coimbra e da sua respetiva herança, tanto para a cidade, como no panorama nacional e até mundial. É feita igualmente a apresentação do Arquivo Sonoro do Centro Histórico de Coimbra – do jacc, elaborado sob direção artística Luís Antero –, com o qual este projeto foi iniciado.

03. Estado da arte

Neste capítulo encontram-se estudos teóricos, onde se pretende procurar uma definição para arquivo e discutir a sua utilização. Em seguida, apresentam-se os paradigmas atuais no desenvolvimento de interfaces, assim como as boas práticas do desenvolvimento web.

04. Casos de estudo – conteúdos, interfaces, identidades

Neste capítulo é feito o estudo, análise técnica e opinião crítica sobre outros arquivos digitais existentes – conteúdos, interfaces, identidades gráficas, etc. – e outras plataformas semelhantes.

05. Metodologia e Planificação

Neste capítulo consta uma breve clarificação do método de trabalho adota-do para o desenvolvimento do projeto, assim como a planificação e calendarização das tarefas necessárias para a conclusão do projeto em tempo útil.

6


06. Projeto

Neste capítulo é feito um relato do desenvolvimento prático das várias fases do projeto – recolha de requisitos, imagem gráfica, design e programação da plataforma, e material de divulgação.

07. Testes

Neste capítulo apresentam-se os resultados dos testes de usabilidade e performance feitos ao website. Explicitam-se ainda quais os problemas resolvidos ou que se deixaram para resolução futura.

08. Conclusões e perspectivas futuras

Neste capítulo é feita uma retrospetiva sobre desenvolvimento do projeto. São assinalados quais os objetivos alcançados ou não alcançados, quais as pers-petivas para a continuidade do projeto e quais as mais-valias pessoais adjacentes a tê-lo desenvolvido

7

pArA umA melhor compreensão deste trAbAlho, é fundamental dar a conhecer o Centro Histórico de Coimbra, a sua relevância para a cidade e a importância dos projetos de intervenção social e cultural nessa zona. E para que se perceba como começaram os trabalhos do Arquivo Digital, é ainda importante introduzir o arquivo sonoro criado pelo jacc, sob a direção artística de Luís Antero.

1. HistóriaO que se conhece hoje como o Centro Histórico De Coimbra, isto é, a zona que compreende a Alta e Baixa da cidade, foi o berço desta cidade à beira rio, que capitulou em 714 aquando das ocupações muçulmanas à Península Ibérica. Na altura, esta era a maior urbanização a norte do Tejo.

Com os islâmicos, definiram-se os nomes Almedina e Arrabalde para as zonas de dentro e fora de muralhas, respetivamente. Almedina é, ainda hoje, o nome de uma freguesia no Centro Histórico, assim como de um dos mais importantes monumentos – a porta e arco de Almedina. Também foi nesta altura que o atual Paço Real, na Alta, passou a ser o localde habitação dos governadores da cidade. Em 1064, a cidade foi reconquistada pelo cristãos, com D. Fernando I. O que se seguiu é também importante de ser contextualizado: em 1096, os condados de Portucale e de Coimbra foram entregues a D. Henrique, pai de D. Afonso Henriques. E é no entretanto, em 1128, que este derrota a sua mãe Teresa na batalha de São Mamede (Guimarães) e que, em 1139 (Ourique), derrota os mouros, declara independência e se torna no pri-meiro rei de Portugal. Agora rei, D. Afonso Henriques instala-se em Coimbra, no Paço Real, fazendo da cidade a sede do reino. Foi aqui que nasceram seis reis de Portugal.

Centro Histórico de Coimbra

8

Arquivo Digital do Centro Histórico de Coimbra 02. C.H.C

Em 1535, nasce a rua de Santa Sofia – uma importante rua da Baixa –, onde foram instalados os colégios universitários para albergar estudantes e dar formação base preparatória. Em 1537, a Universidade é definitivamen-te instalada aqui. Sete anos depois, em 1544, a Universidade muda-se para o Paço Real, onde outrora tinham sido os aposentos reais.

Na Figura 1, podemos ver uma representação de Coimbra poucas décadas mais tarde (1572), naquela que é a mais antiga estampa da cidade.

Figura 1 – Illustris Civitatis Conimbriae Ad Flumen Mundam Effigies. A mais antiga estampa de Coimbra, de Georg Hoefnagel (publicada em 1572). Retirado de www.cm-coimbra.pt

9

Já no século xviii, são construídos novos edifícios destinados às novas faculdades. Na Figura 2, podemos ver uma representação da cidade.

"Para além do património arquitectónico a Universidade marcou profundamente a dinâmica social, cultural e económica de Coimbra." (Raquel Magalhães em História da Cidade – cm-coimbra.pt , 2018)

No século xix a urbanização expandiu-se. Levantou-se o Mercado de D. Pedro v, fizeram-se arranjos na Baixa e beira rio, e muitas outras obras em diferentes zonas. Na Figura 3, podemos ver uma representação da cidade (e beira rio), durante o século xix.

No início do século xx, mais precisamente em 1911, foi inaugurado o serviço de elétricos, que permitiu o crescimento da cidade ligando o centro às zonas residenciais (Figura 4). Na Figura 5, podemos ver uma representação topográfica da cidade na altura.

Figura 2 – Conimbricae, Lusitanea Urbs Ad Mundam Aquaeductu Sebastianis Regis Celebris. Elabo-rada no Século xviii, de Nicolas Ten Horne (publicada em 1718). Retirado de www.cm-coimbra.pt

02. C.H.C

10


Figura 4 – Elétrico em Coimbra no século xx. Retirado de www. metromondego.pt

Figura 5 – Folha 16 da Planta da Cidade de Coimbra, AHMC/ Planta da Cidade, 1934. Retirado de www.eventos.letras.up.pt

Figura 3 – Cidade de Coimbra, de Legrand (publicada em 1839). Retirado de www.cm-coimbra.pt

02. C.H.C

11

Mais recentemente, nas décadas de 40 e 50 do século xx – durante o Estado Novo –, foi demolida parte da zona residencial da Alta de Coimbra para a construção do complexo monumental da Universidade (Figura 6 – antes, Figura 7 – durante, Figura 8 – depois). Isto levou à construção de novos bairros para o realojamento dos residentes – Bairro Norton de Matos, de Celas e das Sete Fontes – expandindo a cidade para novas zonas.

Por toda a sua longa história, a cidade, e principalmente o Centro Histórico, herdou um enorme e valioso património arquitectónico, cultural e natural – como são a Sé velha, o Paço Real, a Igreja de Santa Cruz, o Jardim Botânico, a Porta e o Arco de Almedina, assim como as tradições académicas, como a Queima das Fitas, a Festa das Latas e o Fado/Canção de Coimbra.

"A cidade acolhe um património com um valor arquitectónico, cultural e natural de grande interesse que reflecte os grandes momentos da história, não só de Coimbra, como de Portugal." (Raquel Magalhães em História da Cidade – cm-coimbra.pt , 2018)

Figura 6 – Coimbra antes das demo-lições, na década de 30 do século xx. Retirado de www.pinterest.pt/pin/107312403593264167

Figura 8 – Coimbra. Cidade universitária (vista aérea), 1979. Retirado de www.prof2000.pt

02. C.H.C

12


2. AtualidadeAtualmente, como refere Magalhães (2011), o Centro Histórico de Coimbra está ocupado sobretudo por comércio e serviços, tendo vindo a perder a sua função residencial.

"Os comerciantes da Baixa de Coimbra enfrentam a mais grave crise das últimas décadas, com quebra de vendas e encerramentos que acentuam a desertificação do centro histórico." (Agostinho Franklin em Diário as beiras, 2012)

“Temos problemas com os nossos fornecedores, porque pagamos cada vez mais tarde.” “Há muitas lojas encerradas. Há outras de que se fala que podem vir a encerrar.” “Há menos polícias na rua. Tudo se conjuga, a crise acentua-se com os assaltos” (Arménio Pratas, dono de um pronto-a-vestir na rua

da Sofia em Diário asbeiras, 2012)

“O declínio da Baixa de Coimbra começou em 2000”, recordou Francisco veiga, da firma Modas veiga, ao lamentar que a cidade esteja hoje “cercada por grandes espaços comerciais”. (Agostinho Franklin em Diário asbeiras, 2012)

"...população envelhecida e em várias situações de carência, numa área cujo número de habitantes tem vindo a cair." Entre os problemas mais frequentemente apontados pelos comerciantes estão a prostituição e a toxico-dependência." "...assiste-se a um abandono de funções e serviços da zona." (Camilo Soldado em Público, 2017). Coimbra)

Em 2013, o Centro Histórico de Coimbra deixou de ser apenas a mais importante zona da cidade, para passar a ser uma muito importante zona para o país e para o resto do mundo. Nessa data, a Alta, a Universidade de Coimbra e a rua da Sofia (Figura 9) ganharam o título de Património Mundial da unesco e uma enorme responsabilida-de em continuar a merecê-lo mais e mais.

Figura 9 – Universidade de Coimbra – Alta e Sofia. Retirado de www.cm-coimbra.pt

02. C.H.C

13

Contudo, há vários anos que vários problemas assolam esta importante zona. A descentralização do comércio para as grandes superfícies causou uma enorme diminuição do volume de visitantes e potenciais clientes das lojas da Baixa. Isto veio a causar o encerramento de vários estabelecimentos e causou um ciclo vicioso de problemas, sendo que, ainda hoje, e apesar das várias intervenções meritórias de diversas entidades, se notam os problemas de en-cerramento, degradação dos edifícios, e até de droga e prostituição. Por todos os motivos sociais óbvios que isto acarreta, esta é uma zona que continua a carecer de incansáveis e urgentes intervenções.

Porém, como se referiu anteriormente, várias intervenções começaram já a ser feitas. Projetos como a Agência para a Promoção da Baixa de Coimbra (2004) – que promove a Baixa "...enquanto área em que se conjugam Comércio, Cultura, Turismo e Lazer." –, como o Há Baixa (2004) – que se baseia em "...pequenas intervenções de reabilitação sobre habitações e espaços comerciais..." –, ou, mais recentemente, como o Coimbra Cartaz Cultural (2012) – uma "...agenda informal de eventos culturais, desportivos e de lazer..." – foram responsáveis por algumas dessas intervenções físicas ou de dinamização.

“A Universidade de Coimbra — Alta e Sofia é detentora de um singular conjunto de atri-butos excecionais, cuja importância se estende para além do seu contexto nacional e abrange uma dimensão internacional.”

(Direção-Geral do Património Cultural em patrimoniocultural.gov.pt, s.d)

02. C.H.C

14


“Para Arménio Pratas, « a Baixa é apetecível » e pode ainda reerguer-se das cinzas."

(Agostinho Franklin em Diário asbeiras, 2012)

Ao falar de intervenção e dinamização do Centro Histórico, não se pode deixar de falar de mais dois grandes projetos. Primeiro, o Círculo de Artes Plásticas de Coimbra (1958) – "a mais antiga instituição nacional dedica-da à promoção da arte contemporânea" – que tem, desde há muito, e cada vez mais, promovido os mais diversos tipos de arte na cidade. Esta instituição é responsável pela bienal de arte contemporânea anozero (que vai já na segunda edição). Depois, o Jazz ao Centro Clube (jacc) (2003) – uma associação para a promoção de cultura –, juntamente com o Salão Brazil (2012) – uma sala de espetáculos no coração do Centro Histórico, gerida e programada pelo jacc. Estes têm representado um enorme meio difusor de música e cultura, promovendo concertos, exposições, performances, etc., e, em 2017, avança-ram com a proposta do Arquivo Digital do Centro Histórico de Coimbra – desenvolvido à luz desta dissertação.

Todos estes projetos têm tido sucessos consideráveis mas, para que assim se continue, é crucial perpetuar o os trabalhos de intervenção. O Arquivo Digital é uma forma de o fazer. Este projeto pode ser o englobar de várias destas intervenções de dinamização e conservação do património – pelo menos em memória – e o abrir de portas para muitos outros projetos ou movimentos de intervenção no Centro Histórico.

02. C.H.C

15

Arquivo Sonoro do Centro Histórico de CoimbraDepois disto, para que se perceba como começaram os trabalhos no projeto, é importante conhecer melhor o Arquivo Sonoro do Centro Histórico de Coimbra.

Há muito que o Jazz ao Centro Clube se empenha na preservação do Centro Histórico, inclusivamente do seu ambiente sonoro. O arquivo sonoro, com direção artística de Luís Antero 2, trata essencialmente das pai-sagens sonoras da zona (Figura 10) – as pessoas a passar, os pássaros a cantar, a chuva a cair... tudo aquilo que não se presta atenção, mas que é um retrato do quotidiano daqueles que viveram as épocas gravadas e guardadas neste arquivo. Prova disso é a reação das funcionárias da receção do Convento de São Francisco (Santa Clara, Coimbra), que se comoveram ao reconhecer os sons dos sítios onde passavam todos os dias (o comboio em Coimbra-A, as crianças no Pátio da Inquisição, etc.), quando tiveram o primeiro contac-to com o Mobiliário Sonoro – uma instalação da autoria de Pedro Martins, Tiago Martins, João Bicker e Penousal Machado que, pela primeira vez, dá a conhecer uma seleção de sons do arquivo, através do abrir das gavetas de um armário.

Figura 10 – Mapeamento manual das zonas que foram abrangidas pelo Arquivo Sonoro do Centro Histórico de Coimbra (gravações de Luís Antero), sobre uma ima-gem retirada de maps.google.com

2. Luís Antero é um artista sonoro que, desde 2008, desenvolve um trabalho de recolha e documentação do património imaterial sonoro. É curador da netlabel Green Field Recordings, dedicada à edição de trabalhos sonoros com base em gravações de campo e faz/fez parte de vários programas de rádio.

Foi artista convidado e um dos responsáveis pelas gravações do projecto Sons do Arco Ribeirinho Sul, na cidade do Barreiro e director artístico do recente Arquivo Sonoro do Centro Histórico de Coimbra.

02. C.H.C

16


Este projeto – o Mobiliário Sonoro – teve duas versões. A primeira, denominada ms00, consistiu num armário de 16 gavetas (Figura 11), sendo que, a cada uma delas correspondia uma gravação do arquivo. Ao abrir uma gaveta, era reproduzida a gravação correspondente. Quanto mais a gaveta estivesse aberta, maior era o volume do respetivo som. A instalação, interativa, permitia que várias gavetas fossem abertas ao mesmo tempo, sendo possível misturar diferentes paisagens sonoras. A ms00 esteve patente ao público no Museu Temporário de Memórias entre agosto e outubro de 2016.

“Abrem-se gavetas e saem sons do arquivo sonoro.”(J. Delacroix (Ricardo Kalash) em Público, 2016)

Figura 11 – Modelo de debug para o armario ms00. Retirado de cdv.dei.uc.pt

02. C.H.C

17

A segunda versão, denominada ms01, é uma atualização da primeira versão, e foi desenvolvida para a exposição Dar a Ouvir | Paisagens Sonoras da Cidade (de Junho a Setembro de 2017), no Convento de São Francisco. Nesta versão, para além dos sons, foram adicionadas fotografias dos respetivos locais – da autoria de João Duarte, Marco Martins e Luís Antero – ativadas da mesma forma – com o abrir das gavetas – e cujo opacidade é diretamente proporcional ao volume das gravações (e abertura das gavetas). Ou seja, para além de combinar ambientes sonoros, nesta versão é possível combinar os respetivos ambientes visuais fotografados (Figura 12). A exposição Dar a Ouvir | Paisagens Sonoras da Cidade contou com uma performance de encerramento por Luís Antero e Pedro Martins, onde os sons provenientes do armário eram manipulados e combinados com texturas ambiente de guitarra elétrica – “Concerto para gavetas. Sim gavetas!”. Esta instalação e concerto voltaram a estar presentes na edição do presente ano (1 de Julho a 2 de Setembro 2018) da mesma exposição. (Figura 13).

No futuro, pretende-se que o projeto continue, incluindo técnicas não fotorealistas para alterar as fotografias através da análise dos sons.

02. C.H.C

18


Figura 12 – Performance de Luís Antero no dia de abertura da exposição Dar a Ouvir — Paisagens Sonoras da Cidade (2017) no Convento São Francisco. Retirado de cdv.dei.uc.pt

Figura 13 – Performance de Luís Antero acompanhada à guitarra por Pedro Martins, criando uma nova camada sonora. Exposição Dar a Ouvir — Paisagens Sonoras da Cidade (2018) no Convento São Francisco. Retirado de Coimbra explore.com/news/2018/8/20/ concerto-para-gavetas-sim-gavetas

02. C.H.C

19

Antes de começAr A projetAr e desenvolver este projeto, foi importante perceber o que é um arquivo e para que serve. Depois, foi igualmente relevante fazer um ponto de situação do estado atual do desenvolvimento de interfaces e de quais as boas práticas do desenvolvimento web.

1. Arquivos“O que é um arquivo?” não tem uma resposta consensual. De acordo com Leavitt (1961), por volta dos anos 1960, houve algumas discussões entre arquivistas quanto à questão do conceito de arquivo implicar, ou não, a ideia de idade.

Os arquivistas de administração central tendiam a definir arqui-vos como “todos os registos oficiais produzidos ou recebidos por um escritório administrativo no curso de seus negócios” ignorando ou minimizando a questão da idade. Os arquivistas holandeses e ingleses incutiam que existisse preservação, ou seja, uma forte conotação à ideia de idade (Leavitt, 1961):

1. Os arquivistas holandeses Muller, Feith e Fruin – "documentos escritos, desenhos e impressos, recebidos ou produzidos oficialmente por um órgão administrativo ou um dos seus funcionários, pelo menos na medida em que esses documentos se destinem a permanecer na custódia desse corpo ou desse funcionário";

2. Jenkinson, o arquivista inglês – "...[documento] que foi elaborado ou usado no decorrer de uma transação administrativa ou executi-va (seja público ou privado) de que ele próprio formou parte e que, posteriormente, foi preservado sob sua própria custódia para sua própria informação pela pessoa ou pessoas responsáveis por essa transação e seus legítimos sucessores";

3. No Edifício dos Arquivos Nacionais de Washington, “arquivos” são definidos como "Os Registos da nossa vida Nacional" (vida america-na), "O Património do Passado" e "As Crónicas daqueles que Concebe-ram e Construíram a Estrutura da nossa Nação" (nação americana).

Estado da arte

20

Arquivo Digital do Centro Histórico de Coimbra 03. Estado da arte

Mas olhando aos primórdios da palavra, e ainda segundo o mesmo autor, os gregos tinham e têm uma palavra – archí – que significava "o começo" ou “primeira causa”, que mais tarde evoluiu para significados como “o primeiro lugar”, “poder”, “soberania”, depois “império ou “reino” e, de seguida, num sentido mais restrito, para “uma magistratura” ou “escritório”. Entretanto, no plural, teve também significado de “os magistrados” ou “as autoridades” e, finalmente, “o governo”. Entre todas as conotações dadas a esta palavra grega estão dois adjetivos. O primeiro significa “antigo”, “primitivo” ou “velho”, e o outro significa “sítio oficial” ou “sítio governamental”. Mais tarde, os romanos começaram a usar uma palavra derivada deste segundo adjetivo – “archium”. A partir daqui, é possível perceber de onde deriva a nossa atual palavra arquivo.

Nos anos 1990, para facilitar a comunicação entre arquivistas, infor-máticos e afins, o “Dicionário de Terminologia Arquivística”, do Instituto da Biblioteca Nacional e do Livro (1993) formulou uma definição normalizada de “arquivo” mais abrangente:

“Conjunto orgânico de documentos, independentemente da sua data, forma e suporte material, produzidos ou recebidos por uma pessoa jurídica, singular ou coletiva, ou por um organismo público ou privado, no exercício da sua atividade e conservados a título de prova ou informação. Pode significar também a instituição ou serviço responsável pela aquisição, conservação organização e comunicação de documentos de arquivo.” Dicionário de Terminologia Arquivística do Instituto da Biblioteca Nacional e do Livro (1993)

Ainda assim, restringir os documentos a um conjunto orgânico podia ser demasiado limitador em relação às conotações que “arquivo” pode ter nos dias de hoje.

“[T]he question of the archive is not (...) a question of the past. It is not the question of a concept dealing with the past that might already be at our disposal or not at our disposal (...). It is a question of the future, the question of the future itself, the question of a response, of a promise and of a responsibility for tomorrow. The archive: if we want to know what that will have meant, we will only know in times to come.” (Jacques Derrida, 1995)

21

Em 1995, Jacques Derrida argumentou que o arquivo tem que ver com futuro e não com passado – um arquivo requer a intenção de usar os docu-mentos no futuro para formar conhecimento. Ou seja, é o registo do passado que serve de alicerce à construção do futuro – as sociedades constroem a sua personalidade, cultura e política baseadas na sua História. Segundo o mesmo autor (1995), isto concede ao arquivo um enorme poder para moldar o poder político de sociedades. Se alguém puder manipular a documentação de todos os arquivos, poderá ter o poder de manipular toda uma sociedade futura. Isto releva a importância da existência de vários arquivos numa sociedade, para que, ao cruzar documentos, possamos aferir a veracidade do passado.

“ação de arquivar: 2. conjunto documental (manuscritos, livros, fotografias, impressões digitais, etc.) que resulta da entidade de uma entidade ou um serviço; 3. depósito, lugar ou edifício onde está guardado esse conjunto do-cumental; cartório; 4. móvel ou pasta para guardar documentos; 5. figurado pessoa de boa memória; INFORMÁTICA ficheiro.” (Porto Editora, 2003-2017)

Além das definições já apresentadas, procurou-se ainda uma definição mais uniformizada. Como é referido num dicionário atual (Porto Editora, 2003-2017), um arquivo pode ser um "conjunto ordenado de documentos que uma sociedade, instituição ou pessoa elabora no âmbito das suas actividades e funções" (conjunto documental), o lugar onde se guardam esses documentos (sítio), a ação de arquivar (ato) – guardar documentos ou dar um assunto por encerrado (por exemplo, quando alguém diz que vai proceder ao arquivo de algo) – e ainda, no que toca à informática, podemos conotar arquivo como "um conjunto de informação digital que se pode armazenar num computador..." (ficheiro/s).

Segundo a definição anterior, “ficheiro” é uma definição possível para “arquivo”. Tendo em conta o caráter informático deste projeto, definir essa palavra é também importante:

“Ficheiro: 1.caixa, gaveta ou pasta onde se guardam fichas 2. conjunto de fichas 3. catálogo 4. INFORMÁTICA conjunto de informações, programas, etc., armazenado com um determinado nome na memória de um compu-tador ou num suporte de informação.” (Porto Editora, 2003-2017)

Com sustento na definição de dicionário o adchc poderia já ser con-siderado um arquivo – um lugar onde está guardado um conjunto documental (ficheiros informáticos, como áudios, imagens, vídeos ou textos).

03. Estado da arte

22


Porém, admitir a classificação de arquivo apenas porque este é local onde se guardam documentos poderia ser contestável. Nesse caso, este não seria diferente de uma cloud drive ou de plataformas como o vimeo, Pinterest, Flickr, Soundcloud, etc. (que se assemelham pelas funcionalidades de upload e visualização de ficheiros).

Recordando o “Dicionário de Terminologia Arquivística”, num arquivo é necessária a aquisição, conservação, organização e comunicação dos docu-mentos. Todas as plataformas referidas o fazem. Em parte, talvez todas elas possam ser consideradas arquivos. Mas sendo que as mesmas não são trivial-mente conotadas assim, teria de existir uma diferença maior.

Apesar das discórdias, as perspectivas dos arquivistas holandeses e ingleses têm algo em comum. Estes falam em “idade” enquanto “preserva-ção”: mais uma vez, segundo Leavitt (1961), “os arquivistas holandeses e ingleses incutiam que existisse preservação, ou seja, uma forte conotação à ideia de idade”).

A ideia de “guardar/preservar/conservar para memória futura” está igual-mente presente em todas as definições já referidas. Podemos assim concluir que essa é chave para algo possa ser classificação como arquivo.

Isto pode ainda ser comprovado nas descrições de instituições arqui-vísticas como o arquivo da Fundação Mário Soares ou o arquivo da Direção Geral do Património Cultural.

“Os arquivos são essenciais à Memória. Preservar e disponibilizar a docu-mentação dos nossos arquivos é, por isso, uma tarefa de grande prioridade.” “...sublinhamos a importância da conservação dos documentos para as gerações futuras, a confiança que os arquivos devem inspirar em matéria de preservação da autenticidade e da fiabilidade da informação de que são guardiães e a sua relevância enquanto elementos de identidade da memória e da história individual e coletiva” (Fundação Mário Soares, s.d)

“...salvaguarda, inventário, preservação e tratamento das coleções...” (Direção Geral do Património Cultural, s.d.)

Assim, sendo podemos assumir que o adchc é realmente um arquivo, pois quando um utilizador o consulta, tem o intuito e consciência de que os registos foram aí guardados/preservados/conservados para memória e estudo futuros. É esta intenção que distingue o Arquivo Digital do chc de plataformas como o vimeo, Pinterest, Flickr, Soundcloud, etc.

03. Estado da arte

23

2. Design de interação e interfaceInterface

"Each time someone uses an application, or any digital product, he carries on a conversation with the machine. (...) the user interface mediates that conversation, helping users achieve whatever ends they have in mind." (Tidwell em Designing Interfaces: Patterns for Effective Interaction Design, 2010)

“Interface” é tudo aquilo que nos permite comandar um agente para gerar ações (inputs e outputs) – física ou digitalmente. No limite, podemos até considerar que os seres vivos têm uma interface – os sentidos. Uma interface carece de dois principais tipos de agente – os agentes de interação (que tratam da forma/movimento como o utilizador manda desempenhar uma ação) e os agentes de perceção/comunicação (que tratam da forma como o utilizador reconhece/percebe os agentes de interação). Por exemplo, a interface de um website é o conjunto de botões, sliders, etc. que controlam as ações possíveis, assim como todos os meios visuais que dão feedback ou informação ao utilizador.

Design de interação vs design de interface

"[Interaction design] is about creating user experiences that enhance and augment the way people work, communicate, and interact." (Preece em Interaction Design: Beyond Human-Computer Interaction, 2011)

Design de interação é o projetar dos agentes de interação de uma interface, ou seja, como se interage com ela. Presentes nos dispositivos mais comuns, existem vários exemplos de gestos de interação ou formas de visualização de informação intuitivas que não necessitam de aprendizagem. Por exemplo, num dispositivo móvel, para mover uma página web para cima, arrastamos a página para cima – touch scroll. Isto é uma metáfora para o arrastar de uma página ou objeto real. Para fazer zoom-in, tocamos com dois dedos e alarga-mos a distância entre eles – o zoom-in é uma metáfora para o ato de esticar/aumentar uma superfície. Estes são exemplos de design de interação que tiram partido de movimentos físicos do mundo real (ações).

03. Estado da arte

24


O design de interface é o projetar dos restantes agentes – os agentes de perceção/comunicação (a parte visual da interface). Ir para o ecrã principal clicando no pictograma de uma casa, ou fechar uma janela clicando num “x” são exemplos de design de interface que tira partido de standards culturais, pois o significado destes símbolos está já enraizado no senso comum.

Design natural

Design natural pode ser definido como "sem necessidade de explicação , "em que apenas as coisas cruciais são mostradas", "instintivo" (Norman, 1988).

Existem interfaces com propósitos muitos diferentes e que, por isso, têm requisitos muito diferentes. Interfaces para serem usadas muito espora-dicamente devem requerer pouca ou nenhuma aprendizagem. Em interfaces para uso recorrente é tolerável que seja necessário uma maior aprendizagem.

O Arquivo Digital do Centro Histórico de Coimbra pretende estar algu-res no meio, mas mais próximo das primeiras. Por exemplo, um utilizador que quer consultar o arquivo deve perceber em poucos segundos como o fazer, mas não tem que perceber imediatamente que pode consultar aplicações desenvolvidas com a api (Application Programming Interface) do arquivo.

Para auxiliar este trabalho, estudaram-se métodos de design natural.

03. Estado da arte

25

Princípios Básicos da Psicologia das Coisas do Quotidiano

Segundo a investigação de Norman3 (1988), a grande quantidade de funcionalidades presentes nos aparelhos torna-os caóticos, o que resulta em que uma considerável maioria das pessoas não consiga usar grande parte das suas funções. O autor sustenta que a resposta para este problema está no design natural, que é conseguido tendo em conta seis princípios básicos:

1. Finalidades intrínsecas e a priori – affordances: De acordo com Norman, existem nos materiais e objectos finalidades intrínsecas, criadas a priori a partir das propriedades e características visíveis das coisas. Então, um bom design deve criar pistas de utilização naturalmente interpretáveis, tirando partido das coisas que as pes-soas esperam das formas e materiais – coisas complexas requerem explicação, coisas simples não devem requerer ou o design falhou.

Para que serve um puxador? Para que serve uma roda? Ou, no mundo digital, para que serve uma hiperligação? Um puxador serve para puxar, uma roda serve para rodar, uma hiperli-gação serve para clicar. Todas estas são propriedades visíveis de objetos, das quais os utilizadores esperam uma ação inerente – affordances.

2. Restrições – constraints: Uma barra de scroll serve para arrastar. No entanto, apenas se pode arrastá-la até aos limites do seu invólu-cro. A esses limites chama-se de constraints (restrições). Constraints limitam affordances.

Numa interface (digital ou física), limitar visivelmente as af-fordances é tão importante como a própria affordance. Por exemplo, tomando o exemplo da barra de scroll, é importante que o utilizador saiba quando já não pode arrastar mais.

3. Modelos mentais – mental models: Outro princípio básico que o autor introduz é o modelo mental.

É importante que um utilizador seja capaz de se guiar e localizar ao longo das diversas tarefas que desempenhe com um objeto ou sof-tware. Por esta razão, ele deve ser capaz de criar modelos de utilização imaginários através da interpretação da estrutura e ações visíveis do objeto – mental models. Por exemplo, num website é importante que o utilizador não se perca ao navegar, ou seja, saiba a quantas páginas está da página inicial – index –, ou onde se localiza no mapa do site.

3. “Norman é Engenheiro Eletró-nico e Psicólogo. Foi membro da faculdade de Harvard, Univer- sidade da Califórnia, San Diego, Northwestern e KAIST (Coréia do Sul). (...) [Foi ainda] vice- -presidente da Apple e executivo da HP (...). Hoje (...) dedica-se a ajudar empresas de tecnologia a estruturar linhas de produtos e negócio.” (em https://www.nn-group.com/people/don-norman)

03. Estado da arte

26


4. Mapeamentos – mappings: No seguimento, é apresentado o con-ceito de mapping (mapeamento). “Para mover algo para cima, move-se o controlo para cima.” O mapping permite prever a relação controlo-ação ou estado-aparência de um sistema. Bom mapping tira partido de analogias físicas e standards culturais – natural mapping.

5. Visibilidade – visibility: Perceber, através de indícios visíveis, o estado atual de um sistema e as alternativas de ação existentes é aquilo a que Norman chama de visibility.

6. Resposta – feedback: Por último, o autor apresenta a importância do feedback. Um feedback imediato sobre todas as ações de um uti-lizador é crucial para a devida utilização. Para um utilizador, uma ação sem feedback é uma ação não realizada, o que pode conduzir ao abuso do sistema.

Além do seis princípios básicos da psicologia das coisas do quotidiano, existem outros métodos para desenhar interfaces. Dessa forma, é importante conhecer outras perspetivas de como fazer uma boa avaliação de uma interface. Por exemplo, o método de avalição heurística de Jakob Nielsen.

03. Estado da arte

27

Heurísticas de Jakob Nielsen para a avaliação da usabilidade

Em 1990, Jakob Nielsen 4 apresentou as 10 heurísticas para a avaliação da usabilidade (Nielsen, 1990) na Conference on Human Factors in Computing Systems (Nova York) :

1. Visibilidade do status do sistema: O utilizador deve ter feedback do que está a acontecer em tempo real (com delay impercetível);

2. Correspondência entre o sistema e mundo real: Deve ser usada linguagem do mundo real (comum para os utilizadores) em vez de termos técnicos/informáticos;

3. Controlo e liberdade do utilizador: O utilizador deve poder decidir quando quer abortar uma ação ou voltar atrás no sistema;

4. Consistência e padrões: Ações semelhantes devem ser desempe-nhadas de forma semelhante;

5. Prevenção de erros: Deve eliminar-se ou prever situações de erro;6. Reconhecimento em vez de recordação: O utilizador deve ser capaz

de desempenhar ações naturalmente, sem ter que se lembrar como fez da última vez;

7. Flexibilidade e eficiência de utilização: Ao utilizador experiente devem ser revelados atalhos escondidos (combinações de teclas, por exemplo), mas ao o utilizador inexperiente não, para não o confundir;

8. Estética e design minimalista: Só deve ser mostrado o essencial;9. Reconhecer, diagnosticar e resolver erros: Devem existir mensagens

de erro claras e sugestões para resolução dos mesmos;10. Ajuda e documentação: Uma boa interface não deve necessitar

de ajuda. No entanto, esta deve existir, acessível e online, para o caso do utilizador precisar.

Como Nielsen explica no seu artigo “How to Conduct a Heuristic Evaluation”, estas 10 heurísticas são um grupo de argumentos através dos quais podemos avaliar uma interface. Porém, uma deteção de problemas competente pode ser uma tarefa difícil para uma só pessoa. Por este motivo, uma boa avaliação heurística de uma interface resulta do juntar de avaliações de pessoas diferentes (Nielsen, 1995).

4. “Jakob Nielsen, doutorado, é “User Advocate” (designer de interface / interação) e diretor do Nielsen Norman Group, que co-fundou com o Dr. Donald A. Norman (ex-vice-presidente de pesquisa na Apple Computer). Dr. Nielsen estabeleceu o movimento de "discount usability engineering" para melhorias rápidas e baratas em interfaces e inventou vários métodos de usabilidade, incluindo a avaliação heurística. Possui 79 patentes dos Estados Unidos, prin-cipalmente para formas de tornar a Internet mais fácil de usar.” (em www.nngroup.com)

03. Estado da arte

28


3. Fontes web Além da naturalidade de interação, existem outros aspetos que podemos considerar ao avaliar interfaces digitais. Por exemplo, podemos avaliar o tipos de letra usados quanto à qualidade da experiência de leitura. Para isso, estudaram-se alguns conceitos básicos de tipografia.

Para começar, é importante distinguir “tipo de letra” de “fonte”. Segun-do French (2010) 5, um tipo de letra (typeface) é uma família de fontes (fonts). Por exemplo, Adobe Garamond Pro é um tipo de letra, e Adobe Garamond Pro Regular é uma fonte da família Adobe Garamond Pro.

Depois, devemos entender os conceitos de fonte “serifada” e “não se-rifada” que, segundo o mesmo autor, é a maior distinção que podemos fazer entre duas fontes. De uma forma sucinta, serifas são os pequenos adornos das letras. Por exemplo, “Adobe Garamond Pro Regular” é uma fonte serifada e “Helvetica Neue LT Std” é uma fonte não serifada (Figura 14). A Figura 15 refere a diferença entre um caracter serifado (à esquerda) e um não serifado (à direita), estando as serifas estão evidenciadas por circunferências vermelhas.

5. “Nigel French é um designer gráfico e fotógrafo do Reino Unido. É autor da obra InDesign Type, e mais cinquenta títulos na biblio-teca Lynda.com. Foi orador em conferências como PePCon, Adobe max, e na Photoshop and InDesign Conference. Escreve ainda uma coluna sobre tipografia para a InDe-sign Magazine” (em nigelfrench.com)

Figura 14 – Fonte serifada (Adobe Garamond Pro) vs fonte não serifada (Helvetica Neue LT Std)

Figura 15 – Legacy Serif (serifas evidenciadas por círculos) vs Legacy Sans (sem serifas). Retirado de www.fonts.com

03. Estado da arte

29

“Jef Raskin pioneered the use of the word "font" to refer to digital typefaces…” (em The New York Times, 2005)

Existem ainda outros dois termos importantes de conhecer – legibility e readability. Como designa Lupton (2003), “Legibility” refere-se à “facilidade com que uma letra ou palavra pode ser reconhecida (como num exame aos olhos)” e ”readability” refere-se à “facilidade com que um texto pode ser compreendido (como no processamento mental de frases com sentido)”.

Segundo Santa Maria 7 (2004), por um texto ser legível, não quer dizer que seja apetecível à leitura. Ou seja, não é só o extenso tamanho de um texto que pode tirar a vontade de o ler; tipografia “pobre” pode causar o mesmo efeito (Santa Maria, 2004).

Para French (2010), boa tipografia para texto é aquela que é “invisível”. Isto é, um leitor não dá pela presença de boa tipografia, mas percebe quando ela é má.

“Typography exists to honor content.” (Robert Bringhurst em The Elements of Typographic Style, 2002)8

Mas nem todas as fontes são feitas para serem invisíveis. Num corpo de texto pretende-se uma boa readability mas num título pode pretender-se dar priori-dade a chamar a atenção. No entanto, isto não significa que a fonte seja ilegível – tipografia pode não ser fácil de ler mas, ainda assim, ser legível. Posto isto, o que é uma fonte fácil de ler? Como Lupton (2003) refere, o design (e a tipografia) é ainda muito regido por convenções e intuição. Contudo, existem vários estudos sobre a eficiência da tipografia. A autora explicita muitos deles, mas porque esta é uma área difícil de tirar aferições científicas, nem todos eles são consensuais. Ainda assim, é possível tirar alguns ensinamentos importantes sobre a forma como as pessoas leem melhor ou pior.

6. “Jef Raskin, cientista de compu-tação americano (...), revolucionou a indústria dos computadores pessoais por ser um pioneiro no Apple Computer Inc.’s Macintosh, que apresentou uma interface grá-fica user-friendly (“amigável para os utilizadores”) em alternativa aos comandos de texto (...). Os con-ceitos de interface desenvolvidos por Raskin tiveram um profundo impacto na indústria e foram incor-porados noutros programas de sof-tware, como o Microsoft Windows. Raskin foi também creditado por ter introduzido a palavra “fonte” para descrever tipos de letra digitais e esteve entre os criadores da técnica do “click and drag” (clicar e arrastar), que permitiu o movi-mentar de ícones ao longo do ecrã usando o rato.” (em the Britannica Book of the Year)

7. “Jason Santa Maria é um designer gráfico com uma profunda paixão por letras. É fundador da firma de design Mighty, sediada em Brooklyn; membro do corpo docente no MFA Interaction Design program na Escola de Artes visuais em Nova York; cofundador do A Book Apart; e o fundador da Typedia, uma enciclopédia compartilhada online para tipos de letra. Anteriormente, co-fundou a plataforma de escrita colaborativa Editorial; foi vice--presidente da AIGA / NY e diretor criativo da A List Apart e Typekit. Criou sites que equilibram beleza e usabilidade para clientes como a AIGA, The Chicago Tribune, Housing Works, Miramax Films, The New York Stock Exchange, pbs, The United Nations e WordPress.” (em jasonsantamaria.com)

8. Robert Bringhurst é um poeta, historiador, linguista e tipógrafo americano. O seu manual The Elements of Typographic Style tornou-se um dos mais influentes sobre tipografia. Recebeu o prémio Macmillan para Poesia em 1975. (em typotheque.com)

03. Estado da arte

30


No que toca a tipografia impressa, os estudos e a experiência dizem que as fontes serifadas são as mais fáceis de ler por diversos motivos: as serifas criam pontes entre as letras; as fontes serifadas são mais “humanas” por serem mais parecidas com caligrafia; nas fontes não serifadas as letras são mais parecidas umas com as outras, sendo mais difícil de as distinguir – por exemplo, o “i” maiúsculo e o “L” minúsculo; ou como disse Licko (2014) – designer gráfica e tipógrafa, co-fundadora da Émigré Graphics –, talvez seja, simplesmente, por estarmos habituados a ler com serifas:

"Readers read best what they read most." (Zuzana Licko, 2014)

Isto acontece, por exemplo, com a escrita à mão – somos muito rápidos a ler a nossa caligrafia mas lentos a ler a dos outros (não estamos familiari-zados). Há vários séculos que lemos com serifas. Contudo, na web, estamos a habituar-nos a ler com fontes não serifadas. Mas se as fontes serifadas são mais fáceis de ler, qual a razão para que os web designers tivessem começado a usar fontes não serifadas para corpo de texto?

A tipografia em ecrã difere da tipografia para impressão em alguns aspetos. Primeiro, além do envolvente e respetiva iluminação (que também conta para uma boa leitura), os ecrãs têm iluminação própria, o que pode condicionar largamente a leitura. Infelizmente, os designers ainda não podem controlar isto (no futuro, através dos sensores dos dispositivos, pode vir a ser possível controlar o css de acordo com a iluminação exterior – css4). Depois, e principalmente, pelo facto de em ecrã lidarmos com pixels. A densidade de pixels varia de dispositivo para dispositivo e as fontes devem funcionar da melhor forma, pelo menos, na maioria deles. Porém, uma baixa densidade de pixels tende a destruir o desenho original dos caracteres, desfocando-os ou deixado-os pixelizados. Esta limitação de rendering é pior, quanto menor for o tamanho da fonte. Ou seja, a destruição é maior para o corpo de texto – que requer mais legibility – do que para os títulos.

03. Estado da arte

31

Pelo seu desenho mais retilíneo e com menos pormenor (sem serifas), as fontes não serifadas têm a capacidade de ser mais bem renderizadas em ecrã. Na Figura 16, podemos comprar a renderização de uma fonte não serifada (em cima) a uma fonte serifada (em baixo), ambas com um tamanho de 12pts, ampliadas. É possível verificar que a fonte não serifada é capaz de se manter mais fiel ao seu desenho original (Figura 17).

Mas mais importante do que optar por fontes serifadas ou não seri-fadas, é importante optar por fontes especialmente desenvolvidas para ecrã ou, mais especificamente, para a web – extensão woff ou woff2 (versão mais leve de woff). Isto é importante porque, para além de garantirem uma melhor renderização, as fontes web são tipicamente mais otimizadas – fontes pesadas (tamanho do ficheiro) aumentam o tempo de carregamento das páginas web, o que pode conduzir à frustração dos utilizadores e fazer com que estes não esperem pelo carregamento do site.

Mais uma vez, não é só a escolha de uma fonte que faz um texto mais ou menos fácil de ler. Todas as variáveis de paginação são responsáveis por uma boa legibility. Por exemplo, definir siglas e acrónimos em small-caps é determinante para que estes não chamem a atenção mais do que outras pala-vras no texto. Ou definir uma entrelinha apropriada é crucial para encontrar um balanço entre “conseguir encontrar facilmente a próxima linha abaixo” e “não ter que fazer scroll na página constantemente ”. Ou ainda, definir uma boa hierarquia no texto (forma visual de dar diferentes importâncias às diferentes partes do texto) é crucial para ajudar o leitor a situar-se e encontrar o que procura.

Figura 16 – Fonte não serifada (Arial) e serifada (Georgia) com 12pts ampliado

03. Estado da arte

32


Figura 17 – Fonte não serifada (Arial) e serifada (Georgia) com 50pts, sem ampliação.

Pode concluir-se que não existe uma única resposta correta ao escolher uma fonte. Cada caso deve ser ponderado individualmente. Conseguir uma boa legibility depende, não só da fonte em si, mas também da envolvente, iluminação (ambiente ou do dispositivo) e de um bom tratamento de todas as variáveis do texto. Ou seja, depende de tudo aquilo que influencie a disposição do leitor para ler.

Retém-se ainda a importância de que a escolha de uma fonte para corpo de texto seja influenciada por padrões culturais contemporâneos, pois se ontem era natural ler com serifas, amanhã pode deixar de o ser. No presente, os padrões ainda podem ser considerados incertos, principalmente, no que toca a meios digitais.

“Is the right hands, there’s no reason why a sans serif typeface can’t be every bit as readable as a serif typeface. To put in another way, choosing a serif typeface is no guarantee that your type will be readable.”

(Nigel French em InDesign Type, 2010)

03. Estado da arte

33

4. Design responsivo“Small Screen devices are estimated to become the dominant form of web access in a matter of years...” “The long and short of it is that we’re desig-ning for more devices, more input types, more resolutions than ever before. The web has moved beyond the desktop, and it’s not turning back.” (Ethan Marcotte em Responsive web design – A Book Apart, 2011)

Com o crescimento do uso de dispositivos móveis para o acesso à Internet, criou-se uma imensa necessidade de otimização dos websites, para que a nave- gação não fosse condicionada pelos pequenos ecrãs.

Os programadores começaram por resolver o problema criando páginas diferentes para dispositivos diferentes. Por exemplo, através de JavaScript, é possível detetar se a largura do ecrã/janela seria inferior a um determinado valor. Caso fosse, os utilizadores seriam redirecionados para uma página (normalmente, a versão mobile), otimizada para esse dispositivo:

<script type="text/javascript">

if (screen.width <= 699)

document.location = "mobile.html";

</script>

Na Figura 18, podemos ver a comparação do layout de um site em desktop (à esquerda) e em mobile (à direita).

Figura 18 – Layout desktop vs layout mobile. Retirado de smashing magazine.com

03. Estado da arte

34


Mas criar uma nova página para cada resolução diferente, para além de caro, é pouco prático, pouco versátil e praticamente impossível. O design responsivo veio resolver este problema.

“...we can’t keep creating custom solutions for each [device].” Responsive Web design is the approach that suggests that design and de-velopment should respond to the user’s behavior and environment based on screen size, platform and orientation.” (A equipa da revista Smashing em SmashingMagazine.com, 2011)

O termo “responsive design” (design responsivo) foi definido em 2010, por Ethan Marcotte, na revista “A List Apart”. O termo refere que os websites (e outras interfaces) sejam projetados de forma a que se o seu conteúdo se ajuste automaticamente a qualquer tamanho de ecrã ou dispositivo.

“By designing responsively, we can not only linearize our content on smaller devices, but also optimize its presentation across a range of displays.” (Ethan Marcotte em Responsive Web Design – AListApart.com, 2010)

Mas Ethan Marcotte não inventou nenhum tipo de tecnologia. Como disse Keith (2011) “a tecnologia já existia (...) Ethan uniu essas técnicas numa só, mudando a forma como pensamos em web design.”

Existem várias técnicas para fazer design responsivo. A primeira é definir o tamanho dos elementos em percentagens em vez de pixels. Por exemplo, em vez de definir uma largura de 1500 pixels, definir uma largura de 100% da janela. Assim sendo, mesmo que o tamanho ou orientação da janela mude, o respetivo elemento irá ser sempre renderizado com largura igual a 100% da largura da janela:

nav {

width: 100vw;

}

03. Estado da arte

35

Figura 19 – Demonstração da adaptação de vários elementos de uma página web a diferentes tamanhos de ecrã, devido ao uso de percentagens para definir dimensões. Retirado de www.smashingmagazine.com

Na Figura 19 é demonstrada a adaptação dos vários elementos de uma página a dois tamanhos de ecrã diferentes.

Contudo, o mais comum é que isto não seja suficiente para sustentar a maioria dos layouts em janelas ou dispositivos mais pequenos. Assim, para com-plementar a técnica anterior são usadas media queries. Estas podem ser usadas, por exemplo, para detetar o tipo de dispositivo (ecrã, impressora ou dispositivo portátil), orientação (horizontal ou vertical), tamanho e resolução do ecrã. Depois podem ser carregadas diferentes folhas de estilo (css) respetivamente. Por exemplo, se o website for carregado em ecrã (media = ”screen”) – computador, smartphone, tablet, etc. – é usado um determinado ficheiro css; se o mesmo website for car-regado por uma impressora (media = ”print”) é usado um diferente ficheiro css, adaptado a impressão (por exemplo, que não mostre menus):

<link rel="stylesheet" type="text/css"

href="corecss" media="screen"/>

<link rel="stylesheet" type="text/css"

href="printcss" media="print"/>

03. Estado da arte

36


O tamanho (desktop) e orientação (mobile) da janela de um browser poder mudar várias vezes no espaço de segundos. Definir um ficheiro dife-rente para cada orientação ou tamanho exige que o sistema carregue o respetivo ficheiro css no momento de atualizar o layout. Isto torna-se lento e dispendioso.

Para obter uma melhor performance as media queries devem ser incluídas num só ficheiro css. Por exemplo, definir duas colunas de texto para orienta-ção horizontal e uma coluna de texto para orientação vertical. As definições comuns são deixadas fora das media queries:

@media screen and (orientation: landscape) {

body { column-count: 2; }

}

@media screen and (orientation: portrait) {

body { column-count: 1; }

}

body { background-color: black; }

Podemos ainda repensar a forma de apresentação das imagens. Por exemplo, mostrar apenas um corte das mesmas ou agrupá-las num slider/apresentação de diapositivos.

Contudo, para fazer design responsivo, nem sempre basta ajustar o layout dos elementos. Devido ao tamanho limitado dos dispositivos móveis,

por vezes é necessário abdicar de elementos não cruciais. Por exemplo, abdicar de uma imagem em prol do texto ou esconder um menu (Figura 20).

Figura 20 – Sequência ilustrativa do antes (1) e depois (2) de carre-gar no botão “menu” na aplicação Gmail, no sistema operativo Android.(1)

03. Estado da arte

37

“...best practices for mobile environments: simpler navigation, more focused content, lists or rows instead of multiple columns.” (A equipa da revista Smashing em “SmashingMagazine.com”, 2011)

Existe ainda uma questão quanto à performance de carregamento de imagens. Estas têm de ser suficientemente grandes para que mantenham uma boa definição em ecrãs desktop. No entanto, em ecrãs menores (mobile), não só não é necessário que sejam tão grandes, como é importante que sejam mais leves (normalmente, os smartphones e tablets têm menos capacidade de processa-mento e estão muitas vezes ligados a redes móveis, sendo importante poupar largura de banda)

“...If the original image size is meant for large devices, it could significantly slow download times and take up space unnecessarily.” (A equipa da revista Smashing em SmashingMagazine.com, 2011)

Existem várias soluções o problema. Umas operacionais, outras que ainda não passam de propostas. Contudo, todas seguem uma estratégia semelhante – carregar imagens diferentes para dispositivos diferentes. Por outras palavras, carregar a mesma imagem com resoluções, enqua-dramentos, ou níveis de compressão diferentes (Figura 21). Por exemplo, em mobile ser carregada uma imagem mais pequena ou mais comprimida do que desktop.

Figura 21 – Comparação 3 imagens otimizadas para 3 dispositivos diferentes, de Egor Pasko. Retirado de www.smashingmagazine.com

03. Estado da arte

38


No caso de de desenhos vetoriais a solução ótima é bem mais fácil. Consta, simplesmente, no uso direto de ficheiros vetoriais (svg). Por serem um conjunto de instruções de código e não imagens bitmap (em que a cada pixel corresponde um valor de cor), estes podem ser redimensionadas infinitamente sem nunca perder qualidade.

Por fim, ao projetar um website inter-dispositivos, existe ainda uma questão de interação. Em desktop, normalmente, a interação faz-se através do cursor do rato. Porém, em dispositivos móveis o standard é a interação através de ecrãs táteis. Apesar de algumas semelhanças, estes dois domínios têm bastantes diferenças quanto aos respetivos padrões naturais de interação. Por exemplo, em ecrãs táteis é natural fazer swipe (arrastar a página para o lado), mas com um rato não. Também o tamanho dos botões deve ser tomado em consideração pois “clicar” com o dedo é mais impreciso do que com o rato. Por esta razão, em mobile, os botões devem ser suficientemente grandes.

Uma outra diferença problemática entre estes dois domínios é ato de fazer “hover” – “rato sobre” – a um elemento – um evento usado para acionar ações quando o rato está por cima de algo (por exemplo, mudar a cor de um botão para sabermos que é clicável). Em desktop esta é uma ferramenta stan-dardizada e altamente utilizada. A mesma é utilizada para dar feedback de que algo é clicável ou agilizar ações. Por exemplo, possibilita que um utilizador não tenha sequer de clicar para abrir um menu.

O problema é que “hover” não existe em ecrãs táteis. Alguns mobile browsers tentam simular esta ferramenta. Contudo, não a podemos tomar por garantida pois nem todos o fazem. Por este motivo, é importante que não depender do “hover” para desencadear ações fulcrais.

Todas as ferramentas de responsividade faladas podem ainda ser complementadas com JavaScript, para conseguir solucionar todo tipo de pro-blemas ainda não solucionados.

Concluindo, o design responsivo é uma área que continua com muitos problemas por resolver. Por isso, é importante experimentar várias técnicas, estar atento às novidades e partilhar soluções entre developers.

03. Estado da arte

39

5. PerformanceOs estudos sobre o tempo limite que os utilizadores esperam para que um site carregue não são consensuais. No entanto, é consensual que quanto mais tempo demora o carregamento, menos visitas têm os sites. Isto é visível, principalmente, em sites de venda por retalho. Segundo um estudo da Dynatrace (2016) – uma empresa de medição do desempenho de sistemas digitais –, meio segundo de diferença nos tempos de carregamento das páginas pode fazer 10% de diferença nas vendas online. A mesma dá como exemplo a norte americana Nordstrom, que aumentou as suas vendas online em 11% quando o seu website ficou meio segundo mais rápido. Assim sendo, é crucial adotar boas técnicas de otimização.

Antes de iniciar o processo de otimização é necessário perceber o que precisa de ser otimizado. Para auxiliar essa tarefa existem algumas ferramentas, como as consolas dos browsers.

O Google Chrome, por exemplo, permite visualizar o tempo de carrega-mento de cada ficheiro, numa timeline (Figura 22). Desta forma, facilmente, é possível saber quais são os ficheiros mais lentos.

Figura 22 – Timeline de carregamento do Git-Tower, no Chrome Developer Tools.Retirado de www.git-tower.com

03. Estado da arte

40


Imagens

Segundo o Git-Tower (2017) – um website sobre otimização de websites – em média, mais de 60% do peso de um website são imagens. Por este motivo, a otimização das imagens carregadas é de extrema importância.

A melhor forma para otimizar um website quanto ao carregamento de imagens é não as usar de todo. Com css3 (disponível em todos os principais browsers) é possível construir com código, muitos dos efeitos que outrora eram conseguidos com imagens, como sombras, cantos redondos, etc. Utilizar imagens para mostrar texto é outra má prática pois, para além de ser pesado, o texto não vai ser responsivo nem aparecer nas pesquisas. Em suma, imagens devem ser utilizadas apenas quando cruciais.

No caso do uso de imagens ser indispensavel, é importante escolher um formato adequado. Neste aspeto, cada caso é um caso. Como referido no subcapítulo “Design Responsivo”, se uma imagem é suficientemente simples para ser desenhada vetorialmente (logos, ilustrações simples, controlos de interface, gráficos, ícones, etc.), então, o formato svg é a melhor solução. O mesmo não só é mais leve, como pode ser escalado infinitamente sem nunca perder definição. Para obter o máximo de desempenho é ainda importante minificar o código svg. Ou seja, tirar metadados, espaços e parágrafos desne-cessários, usar nomes de variáveis mais curtos, etc.

Caso as imagens sejam fotográficas (ou desenhos/renderings equiva-lentes), muito provavelmente, o formato jpeg é a melhor opção. Este é um formato lossy (com perda), o que significa que o ficheiro guardado vai perder detalhe em relação ao original. Porém, o jpeg está para as imagens assim como o mp3 está para o som. Isto é, tenta eliminar apenas a informação que é percetível (por vezes, não é totalmente verdade). Mas como recomenda o Git-Tower (2017), com alguma experimentação das definições de qualidade, é possível conseguir um bom balanço entre qualidade e tamanho dos ficheiros.

03. Estado da arte

41

O jpeg tem ainda outra particularidade. Para além da “versão padrão” – baseline jpeg –, em que as imagens são carregadas de cima para baixo à medida que os dados são recebidos, existe uma versão “progressiva” – progressive jpeg –, que começa por carregar toda a imagem em baixa definição, e a vai definindo a mesma à medida que recebe os dados restantes (Figura 23).

Existem argumentos contra e a favor desta versão. Carregar progres-sivamente é mais rápido, pelo menos de forma aparente, pois os utilizadores são desde logo presenteados com algo visível a acontecer, dando a sensação que a página carregou mais rápido.

Segundo os estudos de Stoyan Stefanov (2008), um developer da Yahoo, a versão progressiva é, em média, realmente mais leve que a versão baseline. Porém, apenas em média. Segundo o mesmo autor, quanto maior for a imagem, mais provável é que a versão progressiva seja a mais leve. O limiar está nos 10K, ou seja, abaixo deste valor a versão baseline é a mais leve. Acima do mesmo, a versão mais leve é a progressiva.

Figura 23 – jpeg baseline (1) vs jpeg progressivo (2). Retirado de yuiblog.com

03. Estado da arte

(1)

(2)

42


“When your jpeg image is under 10K, it's better to be saved as baseline jpeg (estimated 75% chance it will be smaller); For files over 10K the progressive jpeg will give you a better compression (in 94% of the cases).” (Stoyan Stefanov em Image Optimization, Part 4: Progressive jpeg...Hot or Not? – yuiblog.com, 2008)

No que toca a design, é importante manter a coerência visual. Sendo assim, umas imagens ficarem cada vez mais definidas (progressivas), e outras carre-garem de cima para baixo (baseline) não era uma boa solução.

Stefanov sugere duas alternativas. A primeira consiste em optar apenas por uma das versões jpeg para todas as imagens. A segunda usa a versão baseline para miniaturas (thumbnails) e a versão progressiva para as restantes imagens. Isto mantém a coerência gráfica, criando uma separação lógica entre os dois tipos de imagem, ao mesmo tempo que é capaz de otimizar ambas. Outras situações poderão exigir outras soluções. Assim, cabe a cada designer ou developer tomar a opção mais sensata para o seu projeto.

Existem outras questões sobre estas duas versões jpeg. Por exemplo, a não ser que se discrimine o tamanho da imagem a priori, ao usar a ver-são baseline o browser não vai guardar espaço para ela no layout ao carregar a página. Desta forma, o espaço terá de ser recalculado quando a imagem estiver carregada. Neste caso, o carregamento progressivo é mais vantajoso, pois dispõe desde logo a imagem no layout (mesmo que pixelizada).

Por outro lado, Scott Gilbertson (2013) alega que o jpeg progressivo pode ser frustrante para os utilizadores, pois não sabem quando as imagens estão totalmente carregadas. Não existindo estudos que sustentem a afirmação, cada designer/programador terá de fazer o seu próprio juízo, testando ambas as versões.

“...the most questionable aspect of progressive jpegs is whether or not users actually perceive a fully loaded , but blurry image…”

(Scott Gilbertson em Wired, 2013)

03. Estado da arte

43

O jpeg progressivo tem ainda a desvantagem de que as imagens são carregadas várias vezes à medida que chegam mais dados. Isto é pesado para o processador, o que pode tornar esta versão mais lenta em dispositivos com menos poder computacional. O jpeg, qualquer que seja a versão, para além de não permitir transparência, não é o formato adequado para imagens com cores planas, como formas geométricas, pois irá criar degradês nas extremi-dades dos mesmos.

Caso se pretenda transparência ou definição máxima das formas, muito provavelmente, o melhor formato será o png. Este é um formato com compressão lossless (sem perdas). Ou seja, mantém a qualidade do ficheiro original. Isto implica ficheiros maiores e, consequentemente, mais tempo de carregamento do website.

Porém, também o png tem várias versões. Por exemplo, png-8 (8 bits) ou png-24 (24 bits). Sempre que possível, a versão png-8 deve ser a opção, pois usa uma paleta de cores menor, o que resulta em imagens mais leves. Isto deve ser ponderado caso a caso, experimentando, uma vez que uma paleta de cores menor pode comprometer a qualidade da imagem, princi-palmente, se é uma imagem fotográfica. Por exemplo, para uma imagem fotográfica com transparência – um recorte, por exemplo – provavelmente, o png-8 não se adequaria pelo curto espaço de cor. Igualmente, o jpeg não se adequaria por não suportar transparência. Então, este seria um caso em que o png-24 poderia ser o melhor candidato.

Mas além destes, também o formato webp – desenvolvido pela Google – pode ser uma boa alternativa. O mesmo é 26% mais leve que png e 25 a 34% mais leve que jpeg.

“webp lossless images are 26% smaller in size compared to pngs. webp lossy images are 25-34% smaller than comparable jpeg images at equivalent ssim quality index.” (Google em A new image format for theWeb, 2016)

03. Estado da arte

44


No entanto, o webp não é suportado por todos os browsers, o que faz com que os tradicionais jpeg e png não possam ser dispensados. Ainda as-sim, ter uma versão webp e outra jpeg/png, poderá ser uma boa solução – se o browser suportar o formato é carregada a imagem webp, caso contrário é carregada a imagem jpeg/png.

Na procura pelo melhor formato podemos ainda ponderar o gif (Graphics Interchange Format), que pode servir de alternativa ao png-8. A definição final das imagens é bastante parecida e têm ambos um espaço de cor reduzido. Ou seja, o formato gif apenas deve ser usado em imagens de cores planas. Contudo, este tem a desvantagem de ser mais pesado que png e, ao contrário do mesmo, a transparência do formato gif é sempre binária – ou um pixel é transparente ou é opaco – fazendo do png-8 uma melhor alternativa.

Figura 24 – (1) jpeg 2600×3400 pixels num ecrã 214×280 pixels, 685K; (2) gif; (3) jpeg 214×280 pixels 16K; (4) jpeg 428×560 pixels num ecrã 214×280 pixels, 33K. Retirado de jjohnkuefler.com (3)

(1) (2)

(4)

03. Estado da arte

45

Além da escolha de um formato adequado, é fundamental alertar para que não se usem imagens maiores que o necessário. Por exemplo, como referido em “Design Responsivo”, num smartphone não precisamos de uma imagem tão grande quanto em desktop. Assim, para cada dispositivo, devemos carregar uma versão adequada da imagem. Na figura 24, podemos comparar a definição e peso de várias imagens de tamanhos diferentes, jpeg e gif.

Sobre esta questão, é também muito importante que se dê a conhecer o estudo de Daan Jobsis. Este descobriu que se mantivermos o tamanho de uma imagem duas vezes o tamanho da janela, mas usarmos mais compressão, a imagem será mais leve que a original mas continuará definida, tanto em ecrãs normais, como em ecrãs de retina (duas vezes mais densidade de pixels que os ecrãs normais). Com esta técnica é possível conseguir uma imagem 75% mais leve. Na Figura 25, podemos comparar a definição e peso de uma imagem mais pequena com menos compressão (à esquerda) e uma imagem maior com mais compressão (à direita).

Interessa ainda recomendar o uso de ferramentas automáticas para fazer todo este tipo de otimizações. Existem desde ferramentas para linha de comandos – que podem ser totalmente automatizadas – até ferramentas online ou desktop, as quais podem ser utilizadas para minificar todo o tipo de formatos de imagem.

Figura 25 – Demostração de compressão de imagem por Daan Jobsis. Retirado de www.smashingmagazine.com

03. Estado da arte

46


Animações

“If your only options are slow animation or no animation at all, you’re better off with an interface that just sits there.” (Ezequiel Bruni em The Ultimate Guide to Web Animation – webdesignerdepot.com, 2015)

Da mesma forma que para as imagens, a melhor otimização possível para as animações é não as usar. Porém, algumas animações são tão ou mais indis-pensáveis que algumas imagens, principalmente, no que toca a usabilidade.

A animação na web começou com imagens gif animadas, sendo sobre-tudo uma questão de atratividade/estilo. Mais tarde, o Adobe Flash introduziu uma camada de interação, revolucionando a indústria. As imagens interativas tornaram-se fortes motores publicitários e possibilitaram os jogos de vídeo online – flash games.

Esta duas situações vão já para além de uma exploração meramente estética. A animação é usada para atrair a atenção dos utilizadores para a publicidade (com ou sem interação), assim como na dinâmica e compressão de jogos de vídeo.

A animação para usabilidade (animação da interface) não está muito longe da animação em jogos. Em ambos os casos, esta serve como meio auxi-liar para a compreensão do que está a acontecer ou vai acontecer de seguida. O objetivo é usar animações naturalmente interpretáveis (standards culturais, ou movimentos semelhantes a movimentos do mundo real) para dar feedback ao utilizador. Por exemplo, o preencher de uma barra de processo de carre-gamento ou um loader que gira sobre si próprio para que o utilizador saiba que deve aguardar.

Se uma animação for uma mais-valia para a experiência do utilizador, então é plausível usá-la. Otimizar um website não é apenas fazer com que este seja mais rápido, é também fazer com que ele fique mais fácil e intuitivo (ter um melhor design de interface/interação).

8. Ezequiel Bruni é web/ux designer e blogger.

03. Estado da arte

47

Ao optar pelo uso de uma animação, é importante garantir que a mesma é suficientemente leve e rápida – em performance e duração – para que não atrase a navegação. Cabe ao designer/programador definir a duração das animações de forma a que passem a devida mensagem, mas que não frustrem o utilizador. Normalmente, devem resumir-se a milisegundos.

Por vezes, também a animação estética pode ter um papel de impor-tante. Por exemplo, para que os utilizadores percebam um produto ou marca, ou para contar uma determinada história (storytelling). Estes casos devem ser muito bem contra-balançados para que não comprometam o desempenho do site. Novamente, como refere o estudo da Dynatrace (2016), uns milissegun-dos podem fazer a diferença entre mais um cliente ou menos um cliente. Assim sendo, e mais uma vez, é importante conseguir animações mais leves rápidas.

Nos dias de hoje, o Flash deve ser altamente evitado, pois é pesado e limitado ao interagir com os elementos da página. Por esta razão, os developers começaram a usar JavaScript para fazer pequenas animações. Por exemplo, animar dropdown menus. Com a crescente necessidade de fazer animações mais facilmente e com melhor desempenho, em 2009, foram lançadas as animações css. Hoje em dia, temos a possibilidade de combinar animações css com JavaScript e até svg para conseguir todo o tipo de animação e interação sem recurso ao Flash. Além destes métodos, também o gif também é uma opção. Assim sendo, a lista de discussão consta de quatro métodos plausíveis para animações na web – gif, svg, css e JavaScript.

O método com melhor performance é a animação css. Esta pesa praticamente nada e pode ser otimizada automaticamente pelo browser. Contudo, nem todo o tipo de animações é igualmente pesado. Paul Lewis e Paul Irish justificam o porquê no artigo “High Performance Animations”, publicado em html5rocks.com, em 2013.

03. Estado da arte

48


Numa página web, existem várias camadas de carregamento. Quando mais abaixo estiver a camada mais dispendiosa é uma alteração, pois o browser terá de recalcular todas as camadas acima. Segundo os autores, para todos os browsers à excepção do Internet Explorer, em não se sabe, a ordem de carrega-mento das camadas é a seguinte: “Recalculate Style”, “Layout”, “Paint Setup/Paint”, “Composite Layers”.

“The higher up you start on the timeline waterfall the more work the browser has to do to get pixels on to the screen.”

(Paul Lewis e Paul Irish em High Performance Animations – html5rocks.com, 2013)

De uma forma sucinta, aquilo que os browsers conseguem animar a menos custo são as transformações geométricas (transform) e opacidade (opacity), pois apenas interferem com a camada de carregamento mais acima, “Compo-site Layers”. Depois, estão as propriedades da camada “Paint”, como cores, decorações, etc. – color, visibility, text-decoration, background, outline, border, box-shadow, etc. Por fim, com um maior custo de desempenho, estão as propriedades da camada “Layout”, como tamanhos, grossuras, posições, margens, etc – width, padding, display, border, position, float, overflow, top, bottom, left, right, margin, border-width, font-size, font-weight, etc.

No Chrome e Safari é ainda possível animar filtros. Por exemplo, passar uma imagem de “a cores” para “preto e branco”. A animação de filtros tem uma boa performance.

03. Estado da arte

“The more we base our animation on open standards, the more people will actually be able to see it in the first place.”

(Ezequiel Bruni em The Ultimate Guide to Web Animation – webdesignerdepot.com, 2015)

49

Por vezes, no Safari, as animações podem ser substancialmente mais lentas. Para solucionar o problema podem usar-se transformações 3D – transform: translate3d | rotate3d | etc. –, mesmo que vazias – translate3D(0,0,0) ou translateZ(0). Isto vai acionar o aceleramento de hardware, otimizando o desempenho das animações. Porém, é importante não abusar deste pequeno hack, pois o seu uso desmedido pode trazer problemas de performance ao invés vez de os resolver.

Tudo isto se aplica caso se animem as mesmas propriedades em Java Script. Apesar da animação css ser o método mais leve, este tem capacidades limitadas. Para ter um maior controlo (começar, pausar, recomeçar, inter-romper, cancelar, etc.) ou construir animações mais complexas, é necessá-rio o recurso a JavaScript. Por exemplo, o efeito parallax apenas podem ser conseguido dessa forma.

JavaScript permite várias formas de animar. Por exemplo, através do Web Animations api, é possível criar e acionar animações css. Outra forma é controlar as propriedades dos elementos através do método “request- AnimationFrame”. Este tem também uma excelente performance por ser capaz de ajustar o framerate das animações às capacidades do dispositivo. É ainda possível criar animações usando o elemento canvas. O mesmo pode ser usado para criar qualquer tipo de gráficos 2d ou 3d bitmap, mantendo um bom desempenho. Todavia, sendo este renderiza frames bitmap, a resolução das animações pode não ser a ideal em ecrãs de retina.

Em relação às animações css, o JavaScript tem a desvantagem de poder perder frames, resultando em animações menos mais suaves.

Por fim, falta apresentar as animações svg ou, por outras palavras, o “smil” (especificação nativa para animações svg). O smil permite todo o tipo de interação com o conteúdo svg, desde transformações geométricas, mover elementos ao longo de percursos (“follow path”), ou até metamorfoses (“morphing”). Esta é uma ferramenta poderosa, mas que não tem suporte por parte de todos os browsers, como o Internet Explorer ou o Microsoft Edge.

03. Estado da arte

50


Durante um período, também o browser Chrome deixou de suportar smil em prol da animação css. Contudo, o suporte já foi novamente concedido.

Mas uma vez que o suporte para smil é instável, é importante asse-gurar soluções sólidas. Em 2015, Sarah Drasner publicou um artigo que visa resolver esta questão. O artigo foi publicado em css-tricks.com e chama-se “smil is dead! Long live smil! A Guide to Alternatives to smil Features”. O mesmo foi escrito antes do Chrome voltar a suportar smil. No entanto, as soluções de Drasner continuam boas alternativas na atualidade.

Muitas soluções passam, simplesmente, pelo uso de css. Por exemplo, já é possível fazer com que um elemento siga um percurso usando apenas css (motion-path e offset-path). Também já é possível fazer metamorfoses apenas com css (d:path). Contudo, prevalece o problema do suporte –apenas o Chrome suporta metamorfoses, e o Internet Explorer não suporta “seguir percursos”.

Outra solução é o uso de bibliotecas JavaScript, como por exemplo o Snap.svg, anime.js, svg Morpheus, HUE.js, etc. Uma das mais versáteis biblio-tecas apresentadas é o GreenSock. Esta não só facilita a criação de animações, como é capaz de fazer complexas metamorfoses. Além disso, e mais impor-tante, é capaz de resolver os problemas de incompatibilidades dos browsers. Ou seja, tudo será funcional, mesmo no Internet Explorer.

Concluindo, seve dar-se prioridade a animações simples que realmente ajudem o utilizador e, preferencialmente, programadas em “css universal”.

03. Estado da arte

51

Vídeo

No seguimento, importa ainda falar de vídeo. Usar vídeo para mostrar peque-nas animações não deve nunca ser opção. Para uma boa otimização, assim como com os media anteriores, o vídeo deve ser usado apenas quando realmente necessário. Além disso, é importante que a sua reprodução só seja iniciada por vontade do utilizador, e não automaticamente. Ou seja, não se adequa a animações.

Existem vários formatos disponíveis para vídeo na web, como wmv, flv, mov, webm, ogg e mp4. Contudo, para uma melhor otimização, apenas interessam aqueles que puderem ser convertidos em vídeo html5 (só não tem suporte em Opera mini), ou seja, mp4, webm e ogg.

Nenhum destes formatos é suportado por todos os browsers. Contudo, webm e mp4 são aqueles com melhor suporte e melhor relação qualidade/peso. Assim sendo, uma boa solução poderá passar pelo uso de webm – mais leve que mp4 – como padrão, juntamente com a disponibilização de uma versão mp4 para os browsers que não suportem o primeiro.

Depois de definir um formato, é ainda importante certificar que o ficheiro de vídeo é suficientemente leve. Para isto, podem ser utilizadas ferramentas de compressão como o ffMpeg ou HandBrake. Estas removem metadados desnecessários e reduzem a quantidade de dados transmitida por unidade de tempo (bit-rate).

Uma outra opção de otimização é o recurso a Content Delivery Networks (cdn) – redes de servidores especializados, criadas para acelerar a velocidade de transmissão de dados. Contudo, estas acarretam custos monetários.

Até aqui, falou-se de vídeo alojado por conta própria – self-hosted video. No entanto, na maioria dos casos, esta não é a melhor opção. Self-hosted videos têm a vantagem de não ter publicidade, nem sugestões de outros vídeos no final. Contudo, estes ocupam muita largura de banda e espaço no servidor. Geralmente, os web hosts (servidores onde se alojam páginas web) têm um limite reduzido de espaço para carregamento de ficheiros, assim como um limite máximo para a duração dos vídeo carregados. Se os vídeos estiverem alojados num só servidor com largura de banda limitada, é muito provável que a reprodução dos mesmos aconteça com interrupções.

03. Estado da arte

52


Desta forma, uma melhor alternativa é carregar os vídeos para serviços especializados, como o YouTube ou o vimeo, e embuti-los no website pretendido (uma linha de código):

<iframe src="https://player.vimeo.com/video/238283378"

width="640" height="360" frameborder="0"></iframe>

Fazer isto não só proporciona uma melhor transmissão de vídeo, como descarta o trabalho de compressão e compatibilidade de browsers, pois estas otimizações são feitas, automaticamente, por estes serviços. Além disso, o facto dos vídeos estarem disponíveis numa rede social, como o Youtube ou vimeo, aumenta largamente a possibilidade de serem vistos, podendo servir como meio de ligação ao website criado.

À semelhança das imagens, especificar o tamanho do vídeo para cada dispositivo ou ecrã pode ser altamente vantajoso, pois isto garante que o browser não carrega frames maiores que o necessário.

03. Estado da arte

53

Casos de estudo Antes de dAr início Ao desenvolvimento prático do projeto era importante fazer um estudo sobre as interfaces, conteúdos e identidades de alguns arquivos digitais existentes. Para isto, analisou-se um total de vinte e cinco arquivos, especializados num ou vários tipos de conteúdo em simultâneo, entre imagens, sons, vídeos ou textos.

Desse conjunto de vinte e cinco arquivos (Anexo 1), selecionaram-se cinco para serem descritos e analisados. Essa escolha prendeu-se com a rele-vância dos mesmos no contexto deste projeto. Em particular, no que toca à organização de conteúdos, existem 3 plataformas com semelhanças à plata-forma do adchc.

Porto Sonoro – portosonoro.ptO intuito do projeto Porto Sonoro assemelha-se ao do Arquivo Sonoro do Cen-tro Histórico de Coimbra – “...pretende registar, restaurar, recriar e catalogar [o património sonoro do Centro Histórico do Porto]” (a equipa do Porto Sonoro, s.d.). Por esta razão, não podia deixar se ser referenciado.

Ao entrar na plataforma, é mostrada uma página introdutória onde é identificado o projeto e as respetivas entidades responsáveis. Aí é ainda apre-sentada uma composição de imagens de orelhas, sustentando o teor áudio do projeto (Figura 26). A composição de imagens de orelhas funciona ainda como menu principal – ao passar o rato por cima de algumas das imagens (não todas), são revelados links de navegação (Figura 27).

54


Figura 26 – Página inicial do Porto Sonoro. Retirado de www.portosonoro.pt

Figura 27 – Página inicial do Porto Sonoro – links mostrados quando o rato está em cima de uma das imagens (a imagem a vermelho). Retirado de www.portosonoro.pt

Esta abordagem acarreta graves problemas de usabilidade, pois é extre-mamente difícil perceber quais são as alternativas de navegação possíveis. Mais ainda quando nem todas as imagens escondem menus. Estes aspetos resultam num atraso excessivo na navegação. Uma melhor opção poderia ter sido que a página inicial fosse a página de “Cartografia Sonora” (Figura 28), onde é possível ter acesso ao arquivo.

Figura 28 – Página “Cartografía sonora” do Porto Sonoro. Retirado de www.portosonoro.pt

04. Casos de estudo

55

Nesta página – “Cartografia Sonora” – os conteúdos são dispostos geograficamente através da api do Google Maps. Esta terá sido uma boa opção, pois o modo de interação desta ferramenta é conhecido da maioria dos utilizadores. Além disso, a mesma é bastante eficaz para a visualização geo-gráfica de informação

Este arquivo conta com várias categorias de som, como “Percursos Sonoros Imaginários”, “Vozes”, “Identidades”, “Características”, “Especi-ficidades”, “Celebrações” e “Ressonâncias”. Contudo, pode ser discutível se todas as categorias são sugestivas daquilo que representam. Por exemplo, o que representa “Identidades”? Talvez o problema pudesse ser atenuado se as categorias tivessem uma descrição sumária.

Cada categoria é distinguida no mapa através de um ícone de cor diferente. Usar a cor como variável visual para distinguir elementos é fun-cional até um certo número de elementos. Neste caso, com um total de sete elementos diferentes, era possível criar um bom contraste de cor entre os diferentes ícones. Contudo, este não é o caso que se verifica. Por exemplo, as categorias “Identidades” e “Ressonâncias” ou “Percursos Sonoros Ima-ginários” e “Vozes” são identificadas por cores suficientemente parecidas para que se confundam no mapa.

O único método de pesquisa disponível na página é a navegação no mapa, não sendo possível pesquisar com texto ou filtrar os conteúdos por categoria. Isto pode ser limitador para um utilizador que pretenda ouvir um som específico ou restringir-se a uma categoria.

As descrições das categorias estão constantemente sobrepostas ao mapa, aproximadamente, a um quarto da sua largura. Isto ocupa grande parte do espaço útil e condiciona a visualização da informação. Estas descrições poderiam ser colocadas à margem, otimizando largamente o espaço.

Quando è pagina “Missão” (Figura 29), onde podemos ler sobre o projeto, verificou-se que a imagem de fundo, por baixo do texto, dificulta a leitura do mesmo, isto é, ainda se agrava com o pequeno tamanho da fonte. Este é um reparo que se aplica a todo o website.

04. Casos de estudo

56


Figura 29 – Página “Missão” do Porto Sonoro. Retirado de www.portosonoro.pt

Figura 30 – Página “Transformações Sonoras -> Percursos Sonoros -> Rui Penha” do Porto Sonoro. Retirado de www.portosonoro.pt

Na página “Percursos Sonoros Imaginários” (Figura 30) pode ouvir-se uma das peças sonoras. Aí percebe-se a falta de um layout mais equilibrado e que chame a atenção para o reprodutor áudio.

Tecnicamente, o website é suficientemente rápido mas não é responsivo. Isto limita a sua utilização em dispositivos móveis ou janelas menores.

Em retrospetiva, apesar das lacunas de interface assinalados, este é um projeto do qual é possível tirar várias lições transponíveis para o adchc. Por exemplo, ter cuidado com a utilização de cor para distinção de elementos (deve haver suficiente contraste) e ter um sistema de pesquisa através da escrita e da escolha de filtros.

04. Casos de estudo

57

Phonambient – phonambient.comO Phonambient nasceu no decorrer e com o mesmo intuito que o projeto Porto Sonoro, mas à escala mundial – “Pretende registar e preservar numa base de dados digital (...) os sons que caracterizem uma determinada cidade ou região, incluindo paisagens sonoras, sons localizados, excertos musicais, fonética e fonolo-gia. O arquivo criado fica disponível gratuitamente para consulta e utilização” (a equipa do Phonambient, s.d.). Por esta razão, também apresenta bastante semelhanças com o adchc.

Ao entrar na página inicial do Phonambient, é notório que os respon-sáveis aprenderam com o os pontos fracos do projeto anterior – Porto Sonoro. Esta nova plataforma abre diretamente no menu “Cartografia Sonora” (Figura 31) - também existente em Porto Sonoro, mas que só era acessível ao clicar na respetiva opção da página inicial. Este é um ponto positivo, pois o utilizador tem desde logo acesso aos conteúdos.

A visualização cartográfica manteve-se, mas a organização dos con- teúdos é agora feita por agrupamentos (clusters) – ao invés de cada som ser uma instância no mapa, estes são organizados em grupos que se vão expan-dindo à medida que se faz zoom (Figura 32). Por um lado, esta técnica aju-da a sintetizar a visualização, mas por outro, é mais difícil de perceber que tipo de sons estão incluídos num determinado grupo, obrigando o utilizador a fazer zoom para descobrir.

Figura 31 – Página inicial do Phonambient. Retirado de www.phonambient.com

04. Casos de estudo

58


Figura 32 – Sequência ilustrativa de se como visualizar um grupo de sons (fazendo zoom-in). Retirado de www.phonambient.com

(2)

(1)

04. Casos de estudo

59

Nesta nova plataforma foram removidas as descrições para cada tipo de som, assim como as legendas para cada categoria de cor. Terem removido as legendas de cima do mapa foi benéfico para a visualização. Contudo, teria sido importante mantê-las algures (por exemplo, junto às margens da janela, como sugerido para o Porto Sonoro). Em contrapartida, foi criada uma forma de pesquisa escrita (Figura 33), o que representa uma enorme mais-valia em relação ao projeto anterior.

O facto de terem criado um sound player próprio foi também benéfico, pois este permite mostrar informação realmente pertinente para o utilizador (Figura 34).

Já na página “Percursos sonoros imaginários” – que existia já na plataforma Porto Sonoro – o espaço não foi tão bem gerido. Existe um menu para filtrar conteúdos por tipo, assim como fazer uma pesquisa escrita. Isso é positivo. Contudo, o mesmo ocupa demasiado espaço – cerca de metade da altura do ecrã e toda a sua largura. Outra grande parte do ecrã é utilizada pelo cabeçalho e rodapé, deixando um espaço mínimo para os conteúdos – aquilo que é realmente importante (Figura 35). O menu poderia ser diminu-ído para uma barra com poucos pixels de altura, o que proporcionaria uma consulta bastante mais fácil e agradável para o utilizador.

Este site, apesar de melhor que o do Porto Sonoro, também não é total-mente responsivo, o que pode ser limitador. Independentemente disso, este é muito mais um exemplo a seguir que o seu antecessor.

04. Casos de estudo

60


Figura 34 – Sound Player do Phonambient. Retirado de www.phonambient.com

Figura 35 – Página “Percursos Sonoros imaginários” do Phonambient. Retirado de www.phonambient.com

Figura 33 – Formulário para pesquisa escrita do Phonambient. Retirado de www.phonambient.com

04. Casos de estudo

61

Macaulay Library – macaulaylibrary.orgSegundo o próprio site, este é o “...principal arquivo científico de áudio, vídeo e fotografia de história natural, do mundo” e pretende “...promover ativamente o uso desses registos para diversos fins que abrangem a pesquisa científica, a educação, a conservação e as artes” (a equipa do Macaulay Library, s.d.)

Por englobar estes três tipos de media - som, vídeo e imagem -, esta plataforma é também semelhante ao adchc, podendo ser vantajosa de estudar.

Ao entrar na página inicial da Macaulay Library (Figura 36), é mostrada uma barra de navegação (essencialmente, com informações), seguida de uma barra de pesquisa, seguida de vários módulos para mostrar sugestões, notícias, estatísticas, etc. Esta barra de pesquisa disponível ao iniciar o website é um ponto positivo.

Para encontrar uma uma listagem ou galeria de conteúdos, os utilizado-res têm de explorar os diferentes e confusos módulos na página. Esta listagem está disponível através de um pequeno link, no canto superior esquerdo do módulo “Total Media” (Figura 37), relacionado com estatísticas do número de ficheiros de cada tipologia existente. Por exemplo, “Birds” (total de ficheiros relacionados com pássaros). Aparentemente, estes são os únicos links que os utilizadores podem utilizar para aceder às galerias de fotografias, vídeos ou sons. Contudo, sendo tão importantes, eles deviam ser muito mais evidentes.

Uma vez nas galerias, o ambiente é relativamente parecido à pesquisa de imagens no Google, o que faz destas relativamente fáceis de utilizar (Figura 38). Um outro ponto positivo a evidenciar é a forma de visualização dos espetros de som (Figura 39).

Por fim, ao contrário das plataformas analisadas anteriormente, este é um site responsivo, o que é grande ponto a favor.

04. Casos de estudo

62


Figura 36 – Página inicial da Macaulay Library. Retirado de www.macaulaylibrary.org

Figura 37 – Módulo “Total Media”, na página inicial da Macaulay Library. Retirado de www.macaulaylibrary.org

Figura 38 – Galerias de conteúdos da Macaulay Library (1 – Fotogra-fias; 2 – vídeis; 3 – Sons) Retirado de www.macaulaylibrary.org

Figura 39 – Sound player e respetiva visualização do espetro sonoro na Macaulay Library. Retirado de www.macaulaylibrary.org

(1)

(2)

(3)

04. Casos de estudo

63

Biblioteca de Arte da Fundação Calouste Gulbenkian (Flickr) – flickr.com/biblarte

A Biblioteca de Arte da Fundação Calouste Gulbenkian é uma “biblioteca especiali-zada nas temáticas das artes visuais e arquitectura, de produção nacional e interna-cional...” (a equipa da Biblioteca de Arte da Fundação Calouste Gulbenkian, s.d). Esta interessa particularmente por se encontrar numa rede social – o Flickr – que se procurou diferenciar do conceito de arquivo (ver Capítulo 3). Isto vem provar a argumentação feita sobre o mesmo conceito – como foi referido:

“Em parte, talvez todas elas [plataformas como o Flickr, vimeo, etc.] possam ser consideradas arquivos. (...) A ideia de “guardar/preservar/conservar para memória futura” (...) é chave para algo possa ser classificado como arquivo.”

Apesar de ser um perfil numa rede social, as suas publicações têm o intuito de guardar/preservar/conservar para memória futura. Por esse motivo, este perfil do Flickr pode ser classificado como “arquivo”.

Alojar o arquivo numa rede social é ainda uma boa forma de difusão dos conteúdos, pois é mais fácil que o mesmo seja descoberto ocasionalmente ou que as atualizações sejam seguidas. Além disso, os utilizadores estão já familiarizados com o modo de funcionamento da interface do Flickr, a qual se pode considerar fácil e intuitiva (Figura 40). É ainda vantajoso quanto à otimização dos conteúdos, pois a compressão, conversão e gestão de ficheiros é feita automaticamente pelo serviço.

Neste caso, a questão da identidade gráfica não se coloca, além da imagem de perfil (Figura 41). Esta última não é um logótipo do arquivo, mas sim a da Fundação Calouste Gulbenkian - administradora do arquivo. Ou seja, não existe uma identidade própria do arquivo. Analisando essa foto/logótipo, pode verificar-se que a mesma é pouco clara no tamanho em que é mostrada – em pequeno. Além de um “G” – de “Gulbenkian” –, quase só se percebe ruído (que, na realidade, são os cavalos puxando uma carruagem). Pode ainda verificar-se que a mesma está descentrada. Esta poderia ser melhorada simplificando-a e centrando-a cuidadosamente.

04. Casos de estudo

64


Figura 40 – Página inicial (1) e página “Álbums” (2) da Biblio-teca de Arte da Fundação Calouste Gulbenkian no Flickr. Retirado de www.flickr.com/biblarte

Figura 41 – Imagem de perfil da Biblioteca de Arte da Fundação Calouste Gulbenkian no Flickr. Retirado de www.flickr.com/biblarte

Este arquivo tem ainda uma versão website – biblartepac.gulbenkian.pt –, mas que apresenta défices em todos os aspetos que estamos aqui analisados.

Assim como esta biblioteca, também os documentos do adchc poderão vir a estar disponível em redes sociais.

(2)

(1)

04. Casos de estudo

65

Arquivo de Documentação Fotográfica da Direção-Geral do Património Cultural (dgpc) – matrizpix.dgpc.ptSegundo o próprio website, este arquivo “...desenvolve uma atividade fundamen-tal no âmbito da salvaguarda, inventário, preservação e tratamento das coleções de fotografia histórica dos Museus, Palácios, e de outros imóveis afetos à dgpc, tendo ainda à sua guarda relevantes depósitos de outras entidades e particulares” (Direção-Geral do Património Cultural, s.d).

Para o consultar, foi criada uma plataforma chamada MatrixPix. Este nome tem o problema de ser pouco ou nada sugestivo do que é website. Outro problema é a existência de uma página introdutória sem justificação lógica aparente, o que apenas atrasa a pesquisa (Figura 42).

Ter que entrar e retroceder de página, por cada vez que se pretende visualizar uma imagem (Figura 43) atrasa também a consulta. Além disso, a utilização do website pode ser limitada por não ser um site minimamen-te responsivo. À parte disto e de que a imagem gráfica possa ser discutível, a plataforma é funcional.

Daqui podem ser tiradas importantes lições a transpor para o adchc. Por exemplo, não obrigar o utilizador a ter que mudar de página, de cada vez que queira visualizar um ficheiro (som, vídeo, imagem, etc.). Aliás, não mudar de página, sempre que isso não comprometa demasiado o desempe-nho do site. Isto será benéfico pois não será necessário esperar que as páginas carreguem e ajudará o utilizador a situar-se no website.

04. Casos de estudo

66


Figura 42 – Página inicial do MatrizPix. Retirado de matrizpix.dgpc.pt

Figura 43 – Galeria de imagens e página de visualização detalhada de uma imagem do MatrizPix. Retirado de matrizpix.dgpc.pt

(1)

(2)

04. Casos de estudo

67

05. Met./Plan.

o trAbAlho de design e desenvolvimento do projeto foi conseguido seguindo um modelo em cascata (apresentado em 1970 por Winston Royce). O modelo específico do projeto refere ciclos de desenvolvimento entre as camadas adjacentes. Existiu ainda uma exceção – o aparecimento de novos requisitos – que exigiu retornar às camadas iniciais para reformulação de alguns aspetos do projeto e implementação. O modelo referido pode ver-se na Figura 44.

Depois da pesquisa feita para os capítulo anteriores, deu-se início ao projeto prático através da recolha de requisitos em reunião com o jacc – primeira fase do modelo. Para validar estes requisitos, fez-se uma pesquisa e brainstorming sobre as soluções tecnológicas e de design possíveis, e ava-liou-se o tempo de desenvolvimento mínimo necessário cada cada uma. Isto foi conseguido através do diagrama apresentado na Figura 45, onde se pode ver a planificação dos trabalhos desde setembro de 2017 até junho de 2018.

Metodologia e planificação

(nov

os re

quisi

tos)Requisitos

Projeto

Implementações

Testes

Manutenção Figura 44 - Modelo de cascata do desenvolvimento prático do adchc

68

Arquivo Digital do Centro Histórico de Coimbra 05. Met./Plan.

Levantamento de requisitos e estudos teóricos

Identidade gráfica (brainstorm e esquissos/maquetes)

Design de Interface (brainstorm e esquissos/maquetes)

Base de dados relacional(criação da estrutura de tabelas, restrições, etc.)

Site (html,css,js,php)

Redação da Dissertação

Base de dados relacional(inserção dos ficheiros já existentes)

Identidade gráfica (artes finais)

Design de Interface (arte final)

Site(Youtube e SoundCloud apis)

Site (Otimização de desempenho)

Site (testes usabilidade e respetivas retificações)

api próprio(desenvolvimento)

api próprio(deocumentação)

api próprio(desenvolvimento de uma pequena aplicação que faz uso do api)

Divulgação(Cartazes, Facebook, etc.)

2017

Set Out Nov Dez Jan Fev Mar Abr Mai Jun

2018

Figura 45 - Diagrama de planificação do projeto

69

05. Met./Plan.

Feito isto, começaram os trabalhos da fase de projeto. Os mesmos começaram com a imagem gráfica do arquivo. Para isso, foi feita uma pesquisa e brainstorm sobre motivos visuais relacionados com o domínio do projeto, seguida de maquetagem esquemática, maquetes realistas (estáticas) e, por fim, artes finais. O mesmo processo foi aplicado ao design de interface/interação.

Importa ainda relembrar que, como referido no Capítulo 3, o design da interface foi conseguido tendo em mente os "Princípios Básicos da Psicologia das Coisas do Quotidiano", retratados em "The Psychopathology Of Everyday Things" de Donald Norman (1988) – guias para um design natural (sem necessidade de letreiros ou tentativa e erro, e apenas as coisas cruciais são mostradas).

Com as maquetes terminadas começaram os trabalhos de programação ( front-end e back-end) da plataforma e api, e foram concebidos os artefactos gráficos para divulgação do projeto – a terceira fase do modelo. Ainda nesta fase, surgiram novos requisitos que exigiram retornar e redefinir alguns aspetos nas fases anteriores de desenvolvimento.

Terminada a implementação, seguiram-se testes de usabilidade e per-formance – quarta fase do modelo – , e as devidas emendas. As fases de testes e manutenção prolongar-se-ão ciclicamente no futuro.

A planificação apresentada anteriormente pode ser comparada com o real desenvolvimento dos trabalhos, através do esquema demonstrado na Figura 46. No mesmo pode verificar-se que o planeamento sofreu algumas alterações. Nota-se, por exemplo, o aparecimento de novos requisitos e testes informais a utilizadores, que levaram a novos trabalhos de design e programa-ção da interface. Também quanto ao design da identidade gráfica existiram trabalhos adicionais, para reformulação da fonte Fuga. Isto levou a algumas alterações na interface, as quais se optou por não implementar na versão final. Os trabalhos de divulgação e demonstração do potencial do arquivo na arte começaram também antes do previsto com a concretização de instalações audiovisuais, e só mais tarde se desenvolveram os materiais de comunicação conventuais, como cartazes e página de Facebook. Conseguiram-se também novos publicadores para a plataforma, o que exigiu algumas reuniões para discutir quais as suas necessidades e fazer as devidas alterações na plataforma (esta tarefa poderia também ser considerada como testes informais a utiliza-dores). Este conjunto de tarefas fez atrasar o desenvolvimento da api, testes de usabilidade “formais”, otimização do website e redação da dissertação, prolongando também a necessidade de estudos teóricos.

70

Arquivo Digital do Centro Histórico de Coimbra 05. Met./Plan.

Figura 46 - Diagrama de planificação do projeto, comparando o tempo previsto e o tempo real para elaboração das tarefas

Reuniões

Requisitos

Estudos teóricos

Identidade gráfica (brainstorm e esquissos/maquetes)

Design de Interface (brainstorm e esquissos/maquetes)

Base de dados relacional(criação da estrutura de tabelas, restrições, etc.)

Site (html,css,js,php)

Redação da Dissertação

Base de dados relacional(inserção de ficheiros e ajustes necessários)

Identidade gráfica (artes finais)

Design de Interface (arte final)

Site(Youtube e SoundCloud apis)

Site (Otimização)

Site (testes usabilidade e respetivas retificações)

api próprio(desenvolvimento)

api próprio(deocumentação)

api próprio(desenvolvimento de uma pequena aplicação que faz uso do api)

Divulgação(Cartazes, Facebook, etc.)

2017

Set Out Nov Dez Jan Fev Mar Abr Mai Jun Jul Ago

2018

Perído previsto para o desenvolvimento das tarefas Período real do desenvolvimento das tarefasDesenvolvimento de tarefas não previstas

Testes informais

Instalações

Fonte Fuga

Alterações várias



Novos requisitos Novos requisitos

Novos estudos

Novos publicadores Ficheiros ainda não inseridos

X X XX XX X X X X

71

este cApítulo descreve o processo e desenvolvimento prático do sítio web do arquivo. Os trabalhos foram frequentemente apresentados ao jacc, de forma certificar que todos os elementos concretizados iam ao encontro das ideais mais apropriados para o projeto. Neste processo participaram ainda professores do curso de Sociologia da Faculdade de Economia da Universidade de Coimbra – Doutor Paulo Peixoto e Doutora Sílvia Ferreira – e o Centro de Documentação 25 de Abril da Universidade de Coimbra, “...uma das Unidades de Extensão Cultural e de Apoio à Formação da UC (...) [que] visa recuperar, organizar e pôr à disposição da investigação científica (...) material documental (...) sobre a transição democrática portuguesa (...), mas também sobre toda a segunda metade do século vinte português.” (Centro de Do-cumentação 25 de Abril, 2018). O mesmo teve uma participação ativa na cura-doria dos campos e conteúdos dos menus, particularmente em “procurar” e “publicar”. Ajudou ainda a definir quais o termos técnicos a ser usados no contexto da plataforma (ponderando a existência de utilizadores arquivistas e não arquivistas profissionais), assim como dando sugestões referentes ao perfil de utilizador e informação relativa a publicadores/autores.

1. RequisitosO projeto começou com um levantamento de requisitos em reunião com o jacc. Aí delineou-se que a plataforma deveria ser capaz de albergar imagens, vídeos, sons e textos (carregamento de documentos). Esta devia ainda ser desenhada de forma a que, caso se pretendesse no futuro, pudesse passar a albergar igualmente dados estatísticos. Delineou-se também que deveria existir uma forma de consultar e descarregar os conteúdos, para que pudessem ser utilizados em peças artísticas ou outro tipo de projetos (de acordo com uma licença Creative Commons). Por fim, era ainda crucial envolver a comunidade, criando formas de fazer chegar o arquivo às pessoas, assim como de incluir as suas histórias e memórias.

Projeto

72

Arquivo Digital do Centro Histórico de Coimbra 06. Projeto

Para dar início ao projeto, era essencial definir o suporte de desenvol-vimento tecnológico da plataforma. Como a colaboração comunitária era um fator decisivo, pesando as alternativas – aplicação móvel, programa/aplicação desktop ou página web –, foi clara a escolha de desenvolver para web – uma forma rápida e descomprometida de aceder e interagir com o arquivo. Assim, este poderia estar operacional tanto em dispositivos móveis, como em desktop, sem requerer qualquer tipo de instalação.

“the key questions about it [the web] are not to be answered in the nature of its artifacts alone, but in the emerging social forms which are made possible by these new media” (Lyman & Kahle, 1998)

Outro argumento sustentando o desenvolvimento web era o assegurar da longa vida da plataforma. O mundo já está a mover-se para sistemas cloud – uma forma remota (online) de guardar, gerir e processar dados. E já não são só os documentos, fotografias, vídeos e sons que estão na cloud. É também o software – editores de texto, de tabelas, de slideshows, de imagem, de vídeo, de som, etc. Então, cada vez mais, os Laptops e NoteBooks entregam parte das suas tarefas de processamento à cloud. Tanto, que se começa a entrar na era dos ChromeBooks – computadores que só servem para correr um browser (Chrome). Foi também por esta razão que se optou desenvolver para a web.

Durante o desenvolvimento houve algumas alterações nos requisitos que levaram à reestruturação de várias partes do website. Por exemplo, inicialmente, apenas era possível ver um documento de cada vez, assim como um tipo de arquivo de cada vez. Posteriormente, criou-se a noção de publicação, onde são agregados vários documentos. Da mesma forma, outras funcionalidades foram requeridas à posteriori. A maioria foi desenvolvida: menu lateral “sobre”, menu lateral “lista”, página introdutória, períodos em vez de datas exatas, novos campos associados a documentos e publicações, novos campos associados a publi-cadores e autores, etc. Outras funcionalidades anotaram-se como trabalho futuro.

73

2. DesignImagem gráfica

O desenvolvimento da imagem gráfica (marca) do arquivo começou com um brainstorming (Anexo 2). Começou-se por pensar em todos os conceitos visuais e semânticos que pudessem remeter para a ideia de “arquivo” e “Centro Histórico de Coimbra”– “ficheiro”, “documento”, “Baixa”, “Alta”, etc. De seguida, deu-se continuidade a este processo com o auxílio de pesquisas online, e procurou-se cada vez mais restringir os resultados a conceitos visuais – objetos, formas geométricas, etc. Feito isto, encontraram-se alguns motivos visuais interessantes ligados à ideia de “arquivo”, nomeadamente, caixas, gavetas e dossiers com documentos (Figuras 47 a 52), caixas/dossiers em prateleiras (Figuras 47, 48 e 50) e etiquetas como as que se encontram em agendas telefónicas, que separam os documentos com uma margem saída (Figuras 53 e 54). Notou-se ainda a recorrência de uma disposição em pilha (Figuras 47 a 56).

Figura 47- The Performing Archive: Restricted Access is available for exhibitions. Retirado de suzannela-cy.com/the-performing-archive-res-triced-access

Figura 49 - 99 caixas e 55 mil diapositivos a cores da coleção John F. Bjorklund. Cada diaposi--tivo tem informações e imagens dos Estados Unidos e Canadá, de 1960 a 2000. Fotografia de Jeff Mast. Retirado de railphoto-art.org/collections

Figura 48 - Arquivos do Amon Carter Museu. Retirado de cartermuseum.org/library/archives

06. Projeto

74


Figura 50 - Tate Photographic Archive (Paul Mellon Centre). Retirado de paul-mellon-centre.ac.uk/media/_source/collections/tate-photoarchive-2.jpg

Figura 56 - José Maçãs de Carva-lho, "Arquivo e Melancolia", still video, HD, cor, som, 2016. © José Maçãs de Carvalho. Retirado de www.museuartecontemporanea.gov.pt/pt/programacao/1785

Figura 52 - Documentos arqui-vados em gaveta. Retirado de opensourceartschool.com/about- the-uws-fine-arts-archive

Figura 54 - Documentos ordena-dos por ordem alfabética. Retirado de stokedaboutscience.com/wp-con-tent/uploads/2014/08/file-folders.jpg

Figura 53 - Coleção de slides no arquivo Hamburger Kunst uhh, RRZ/Mcc, Mentz, (Archive of Art em Hamburgo). Retirado de warbur-g-haus.de/en/archive/archiv-hambur-ger-kuenstler.

Figura 55 - 100 capas de jornais do dia 12 de Setembro de 2001, por Hans-Peter Feldmann. Foto-grafia de John Berens. Retirado de nymag.com/arts/art/reviews/44477

Figura 51 - Performance de Pedro Martins e Luís Antero com o ms (Mobiliário Sonoro) 01 – uma instalação interativa que permite consultar alguns conteúdos audio-visuais do adchc abrindo gavetas. Retirado de coimbraconvento.pt/pt/agenda/ms01-instalacao-audiovisual

75

Para o logótipo, encontrou-se uma forma simples mas singular de usar a ideia de gavetas com documentos para criar um sistema dinâmico (processo em Anexo 3). A palavra “Digital” – de “Arquivo Digital do Centro Histórico de Coimbra” – passou a poder ser substituída por um ou mais tipos de arquivo – “audiográfico”, “fotográfico”, “videográfico”, “bibliográfico” – empilhados como documentos em gavetas ou caixas. Para completar o conceito, representou-se a própria gaveta/caixa envolvendo os tipos de arquivo num retângulo cuja espessura do contorno coincide com a espessura da fonte. Tudo isto se revelou uma ideia eficiente, não só pelo conceito de design, mas também porque o logótipo poderia funcionar como um menu para filtrar publicações por tipo de arquivo, fundindo a imagem gráfica com a interface (Figura 57).

Um logótipo implica tipografia, pelo que faltava ainda conseguir uma solução adequada neste aspeto. Assim, visualizando o conceito de “Centro Histórico de Coimbra”, achou-se interessante e oportuno usar uma fonte desenvolvida na cidade, ou melhor, inspirada no Centro Histórico.

Depois de alguma procura, encontraram-se duas fontes apropriadas: Quebra e Couraça, de José Maria Cunha. Contudo, estas não estavam con-cluídas num formato final, não sendo possível a sua utilização.

Mais tarde, encontrou-se uma fonte inspirada em dois letreiros da Baixa – Fuga (Figura 58) –, desenhada por Diogo Ferreira (no âmbito da disciplina de Tipografia Avançada da licenciatura em Design e Multimédia na Universidade de Coimbra, orientada por Artur Rebelo), que a cedeu gratuitamente. Esta fonte também não estava finalizada. Porém, foi possível avançar com o desenvolvimento da mesma, em parceria com o autor: Redesenharam-se caracteres (homogeneizando os seus pesos e mantendo-os legíveis em tamanhos pequenos – mínimo de 12 pontos) e conseguiu-se um formato final, pronto a imprimir ou utilizar em browser.

Figura 57 - Logótipo/menu dinâmico para seleção do tipo de arquivo: (1) “aberto” (2) “fechado”

Figura 58 - Imagem ilustrativa do tipo de letra Fuga, desenvolvida por Diogo Ferreira no âmbito da disciplina de Tipo- grafia Avançada da Licenciatura em Design e Multimédia na Universidade de Coimbra, orientada por Artur Rebelo: (1) Antes das reestruturações (2) Depois das reestruturações

(1)

(2)

06. Projeto

(2)(1)

76


Figura 59 - Maquete do formu- lário para recolher a caligrafia dos utilizadores

Usar uma fonte inspirada no Centro Histórico poderia ainda interpre-tar-se como mais uma forma de arquivo – perpetuando a fonte na imagem gráfica do adchc. Assim, o logótipo passaria não só a representar a ideia de arquivo e os tipos de arquivo existentes, mas também a ser ele próprio um arquivo. No entanto, o conceito parecia demasiado rebuscado, pelo que se pro-curou repensá-lo – Como é que o logótipo se poderia tornar num arquivo real?

Uma das grandes preocupações deste projeto era a inclusão da comuni-dade. Assim sendo, revelou-se pertinente que as pessoas tivessem um papel ativo, não só nos conteúdos do arquivo, mas também na sua imagem gráfica. Depois de alguma reflexão, a solução apareceu nada longe da procura por uma fonte inspirada no Centro Histórico – Que tipo de letra seria mais con-ceptualmente apropriado que a caligrafia das pessoas que o fazem crescer o adchc (os publicadores)?

Era preciso assegurar alguma legibilidade e sustentabilidade do conceito. Por isso, a solução teria de passar pelo equilíbrio entre os dois tipos de letra: A fonte digital – Fuga – seria aplicada a títulos e aos tipos de arquivo no logótipo. As restantes palavras – "Arquivo ... do Centro Histórico de Coimbra" – seriam escritas com a caligrafia dos utilizadores.

Ao registar-se na plataforma, os utilizadores devem fornecer os seus dados. Neste momento, poderia ser-lhes pedido que escrevessem com o rato ou o dedo (touch), cada uma das letras de "Arquivo ... do Centro Histórico de Coimbra” numa respetiva quadrícula (Figura 59). Desta forma, conse-guiríamos recolher a sua caligrafia (não era necessário recolher glifos perfe- cionistas, pois era apenas uma questão conceptual; desenhar com o rato seria suficientemente satisfatório). Depois, um algoritmo ficaria responsável por escolher aleatoriamente algumas, sobrepô-las e adicioná-las às restantes partes do logótipo (tipos de arquivo).

06. Projeto

77

Figura 52 – Primeiras maquetes de como o logótipo poderia funcionar em cartazes.

(1) (2) (3)

06. Projeto

Figura 60 - Maquetes do logótipo com a caligrafia dos utilizadores

Usando este método, seria possível gerar resultados diferentes a cada iteração. O logótipo seria assim duplamente dinâmico, pois tanto poderia variar trocando "digital" por um dos tipos de arquivo (adaptando-se a um contexto específico), como trocando entre um sem número de combinações caligráficas diferentes. Nas figura 60 e 61 podem ver-se as maquetes iniciais do conceito. Esta solução acabou não sendo utilizada pois teria de ser sujeita uma experimentação exaustiva. Contudo, não foi afastada a hipótese da sua utilização futura.

A fonte Fuga foi finalizada numa fase quase final da concretização da plataforma. Apesar de já ter sido testada antes na imagem gráfica (com as limitações e imperfeições que teria na altura), perceberam-se limitações maiores aquando a sua implementação.

Devido à densidade gráfica da interface (principalmente do mapa), esta fonte revelou-se demasiado leve para se destacar e assegurar uma boa legibilidade. Como solução, ponderou-se o desenvolvimento de uma versão “bold” – mais pesada. Porém, devido à sua fisionomia, essa tarefa poderia significar o redesenhar de muitos dos caracteres, o que careceria de tempo inexistente e talvez a desconstrução do conceito inicial – os letreiros da Baixa onde foi inspirada.

(1)

(2)

78


Figura 62 - Comparação da fonte Fuga (1) vs fonte Bungee Regular(2) aplicadas à interface

06. Projeto

Por estas razões, optou-se pela utilização da fonte “Bungee Regular” – uma fonte gratuita, pesada (para que se possa destacar contra os restantes elementos da interface) e que funciona de forma equilibrada tanto vertical como horizontalmente. Esta característica é importante, pois os principais menus da interface são identificados horizontalmente. Segundo o seu autor – David Jonathan Ross (2017) – esta fonte celebra a sinalização urbana, o que traça alguns paralelos com a fonte anterior – Fuga – tornando-se conceptual-mente adequada (Figura 62).

(1)

(2)

79

06. Projeto

Era ainda necessário encontrar uma fonte/família de fontes com-plementar, com maior legibilidade e que contrastasse dos títulos, para ser usada nos restantes textos (principalmente em textos longos). Tendo em conta que a imagem gráfica iria ser usada, principalmente, em formato digital, era fundamental assegurar a legibilidade e leiturabilidade em ecrã. Com sustento nos estudos feitos no Capítulo 3, escolheu-se uma família não serifada – “Open Sans” (Figura 63).

Os restantes motivos gráficos da marca inspiram-se e derivam do logótipo: quadriláteros; linhas com a mesma espessura que o contorno do retângulo envolvente dos tipos de arquivo (ou com uma relação de proporcionalidade); disposição de objetos como são dispostos os documentos em arquivos; mesma fonte nos títulos; etc.

Para não comprometer a sua harmonia visual, decidiu-se que todos os artefactos produzidos seriam compostos em escala de cinza (preto RGB 0,0,0 sempre que possível), e uma só cor complementar – vermelho RGB 255,0,0 – para evidenciar elementos necessitados.

Apesar da subjetividade, sendo que esta cor seria usada para chamadas de atenção (“está selecionado”, “é clicável”, “é o documento”, etc.) o vermelho foi escolhido tendo em conta o sentimento de alerta que lhe pode ser associado.

Figura 63 - Bungee Regular aplica-da ao título. Open Sans aplicada ao corpo de texto

80


Figura 64 - Botão de submissão (em cima) vs botão normal (em baixo)

Imagem gráfica aplicada à interface

Todas as regras gráficas descritas anteriormente foram aplicadas à interface: os menus, janelas, botões ou marcadores são retângulos; os seus contornos, fonte para títulos e respetivos tamanhos são iguais ou com uma relação de proporcionalidade com o logótipo; a fonte para títulos e fontes complementares têm a mesma altura das maiúsculas (mesma altura-x não se aplica pois a “Bungee” apenas tem caixa alta) e os vários tamanhos têm sempre uma relação de propor-cionalidade (1.5%); as medidas, tamanhos/margens e posições dos elementos são múltiplos da entrelinha do texto corrido.

Foi ainda importante fazer uma distinção visual clara entre os botões prin-cipais (submissão de formulários, etc.) e os botões secundários (repor campos em branco, escolher coordenadas no mapa, etc.). Isto foi conseguido, primeiramente, invertendo as suas cores. Depois, utilizando a fonte para títulos nos botões prin-cipais e fonte complementar nos botões secundários (Figura 64).

Os botões de submissão de formulários encontram-se sempre no final dos mesmos, garantindo que o utilizador notou a existência de todos os campos. Os botões secundários, que não sirvam para o preenchimento de campos nos formu-lários ou para interagir com o mapa, são mostrados depois do botão de submissão. Exemplos destes botões são o botão para repor campos em branco ou o botão para mostrar campos escondidos.

Ao colocar o rato ou dedo sobre os botões, marcadores ou links, estes são destacados com contorno/sublinhado vermelho, o que transmite a clicabilidade dos mesmos. O Anexo 4 mostra o processo de design da interface.

81

06. Projeto

3. Ferramentas de programação do lado clienteO website foi desenvolvido a partir de um ficheiro em branco, ou seja, não foi usado qualquer tipo de Content Management System (cms), como WordPress, Drupal, Joomla, etc. Isto representa dificuldades acrescidas em vários aspetos. Por exemplo, em conseguir que o website seja totalmente funcional em browsers diferentes, ou por não existir um layout predefinido. Igualmente, não foi usada qualquer tipo de biblioteca. Para programar o lado cliente usou-se html, css e js puros. Apesar do acréscimo no tempo e dificuldade de desenvolvimento, as escolhas referidas permitiram diminuir a quantidade de código, aumentando velocidade de carregamento.

Para agilizar ainda mais o carregamento e interação, a maioria da informa-ção e conteúdos são carregados e processados apenas quando necessários, através de pedidos ajax. As respetivas respostas são recebidas em formato json – publicações, documentos, upload, criação de perfil, etc. Isto permite que o utilizador nunca tenha de recarregar ou sair da mesma página.

Foi usado uma api (Application Programming Interface) para permitir a utilização e controlo de um serviço externo – o Google Maps. Esta decisão poupou tempo e recursos, e permitiu conseguir um sistema de navegação muito mais bem desenvolvido e acurado do que qualquer um que poderia ter sido desenvolvido no tempo existente.

Figura 65 - Mapa visível sob menu lateral graças à transparência deste último

82


4. Desenho da interface e programação do lado clienteImagem gráfica

Definida a imagem gráfica, era tão ou mais importante pensar e desenhar uma interface que, para além de atrativa, fosse fácil e intuitiva. Para guiar esse trabalho, tiveram-se em mente os "Princípios Básicos da Psicologia das Coisas do Quotidiano", retratados em The Psychopathology Of Everyday Things (1988) de Donald Norman.

De uma forma sucinta, isso significa que um utilizador deve ser capaz de perceber onde está, de onde veio e para onde vai na plataforma, que ações pode desempenhar "agora e depois" e como voltar atrás, de receber feedback imediato de todas as suas ações, de perceber naturalmente como interagir com um controlador (um botão ou um slider, por exemplo) – se deve arrastar, se deve clicar – e, por fim, de perceber quando chega aos limites de um controlador (quando já não o pode arrastar mais, por exemplo).

Segundo os princípios descritos anteriormente, pretendia-se que toda a informação pertinente estivesse visível na janela principal antes que o utili-zador tivesse que interagir. Deste modo, optou-se desenha-la de forma a que não fosse necessário o uso de scroll – todas as publicações e menus são visíveis ao iniciar o website.

Pretendia-se ainda que o utilizador nunca perdesse a ligação visual à janela principal, criando assim um modelo mental ótimo. Deste modo, todas as funções da plataforma são executadas a partir da mesma e única página existente – a página principal. Como já referido, isto é conseguido através de pedidos ajax.

Pelo mesmo motivo, a transparência é largamente utilizada em toda a interface – menus laterais, visualização de publicações, etc. Isto permite per-ceber que existem elementos por detrás de outros e quais são esses elementos. Assim, é-se capaz de identificar o estado anterior do sistema (Figura 65).

83

06. Projeto

Página inicial

Ao iniciar o website, começa-se por mostrar uma página de abertura. Na maioria dos casos, uma página inicial pode ser desvantajosa pois atrasa a visualização e interação com a interface propriamente dita. Contudo, neste caso, encontram-se vantagens.

Os elementos base da página de abertura são um fundo branco transparente (transparecendo a interface principal) e um botão “entrar” (no arquivo) que permite fechar a página de abertura. Depois, esta pode ser complementada com dicas de utilização da interface e/ou publicidade a eventos culturais do Centro Histórico, tornando-se numa forma eficaz de comunicação com os utilizadores e que, posteriormente, pode ajudar a agilizar a interação. Quando não se achar que é uma mais valia, esta pode ser escondida até que volte a ser necessária (Figura 66).

Figura 65 - Mapa visível sob menu lateral graças à transparência deste último

84


Visualização cartográfica

Segundo as premissas anteriores, para oferecer uma vista geral e completa – uma boa visibility (Norman, 1988) –, enquanto o volume de dados e velocidade de carregamento o permitirem, decidiu-se mostrar todas as publicações ao iniciar a plataforma. Contudo, isto trouxe diversos desafios.

A primeira decisão a tomar foi a forma de visualização das publicações. Sendo este um projeto sobre uma zona geográfica – o Centro Histórico de Coimbra –, em que cada publicação tem associada uma localização específica, era importante criar uma fácil visualização dessa informação. Assim, decidiu-se dispor as publicações geograficamente, cada uma assinalada no respetivo local de um mapa (visualização cartográfica) (Figura 53). Para isso, utilizou-se a api do Google Maps, com a qual foi possível desempenhar a tarefa de forma pouco dispendiosa e bastante acurada. Sendo o elemento principal da interface, o mapa ocupa toda a extensão da janela.

A referida api disponibiliza ainda uma forma rápida e fácil de pesquisa geográfica, assim como uma excelente visualização e exploração dos marcadores (publicações) através das funções de zoom e arrastamento.

Como a maioria dos utilizadores web estão familiarizados com o Google Maps e respetivas formas de interação, esta pode ser considerada uma ferra-menta de interação natural.

85

06. Projeto

Ponderou-se ainda a implementação de um método “lupa” para fazer zoom-in stantâneo numa zona do mapa escolhida pelo utilizador. Contudo, isto poderia tornar-se redundante, não justificando os custos de desenvolvimento.

Segundo a imagem gráfica criada, decidiu-se identificar as publicações através de marcadores quadrados – brancos com contorno preto. Porém, uma publicação pode variar quanto ao seu estado de aprovação – aprovadas ou por aprovar. Para distinguir estas duas categorias, o contorno dos marcadores “por aprovar” foi implementado a tracejado, expressando a ideia de inacabamento – falta aprovar. As publicações por aprovar apenas são visíveis para o respetivo publicador e equipa do jacc (Figura 67).

Ainda segundo a imagem gráfica, usou-se o vermelho para realçar ele-mentos da interface. Por exemplo, para dar feedback se o rato está sobre um marcador ou botão, se estes foram clicados, etc. No caso dos marcadores do mapa, se tiverem o rato sobre, o seu contorno passa a vermelho (Figura 68). Usando um critério lógico, quando um marcador é clicado, não só passa a ter contorno vermelho, mas também fundo vermelho – clicar num elemento requer o rato sobre o mesmo, logo, o grafismo de um marcador que já foi clicado é igual ao de um marcador com “rato sobre”, mais um acréscimo visual – o fundo vermelho (Figura 69).

Figura 67 - 6 marcadores no mapa – 5 de publicações aprovadas, 1 de uma publicação por aprovar

Figura 68 - Rato sobre um marcador do mapa

Figura 69 - Marcador no mapa cujo publicação está aberta (foi clicado)

86


Pré-visualização

Ao navegar nas plataformas “Porto Sonoro” e “Phonambient”, sentiu-se a necessidade de uma consulta mais ágil. Por exemplo, prever mais rapidamente de que tratava cada um dos sons. Então, no adchc, optou-se por implementar um método de pré-visualização das publicações. Este mostra, no canto superior direito do ecrã, informação acerca da publicação sobre a qual o rato está – titulo, coleção, tipos de arquivo, autor, publicador, data/período de produção, data de publicação e um breve resumo. Caso o utilizador clique na publicação, é aberta uma visualização completa, onde se podem consultar os respetivos documentos.

Inicialmente, ponderou-se mostrar também miniaturas/excertos dos documentos de imagem, vídeo e áudio – miniaturas das imagens, gifs de alguns frames dos vídeos e excertos dos sons. Mas isto trazia algumas questões: como es-colher os ficheiros a ser pré-visualizados e como fazê-lo suficientemente rápido?

Uma solução inicialmente considerada foi pré-visualizar o primeiro ficheiro de cada tipo existente. Ou seja, um máximo de três ficheiros por pré- -visualização – uma imagem, um vídeo e um áudio. Mas esta solução era dema-siado dispendiosa computacionalmente. Outra solução era mostrar uma ima-gem estática de como a publicação se parecia (captura de ecrã). Contudo, isto apenas revelaria, e mal, o conteúdo das imagens. Por último, podia resolver-se o problema dando ao publicador o poder de escolher qual o ficheiro a pré-visuali-zar. Esta talvez fosse a melhor solução das três. Porém, o problema da velocidade de carregamento permanecia.

87

06. Projeto

Para agilizar o carregamento, era necessária a implementação de com-pressores e conversores de imagem, vídeo e som no servidor (ainda não desen-volvidos nesta versão). Feito isto, seria possível visualizar versões mais leves/curtas dos documentos carregados. Depois, seria ainda necessária uma série de testes com vários dispositivos. Só assim poderíamos garantir que os ficheiros seriam carregados suficientemente rápido para que a pré-visualização agilizasse a consulta ao invés de a atrasar. Devido a questões de gestão temporal e não sendo uma funcionalidade crucial, optou-se por não desenvolver para já ne-nhuma das alternativas referidas – o conteúdo de uma publicação é descrito através do seu resumo (Figura 70).

Sendo que a pré-visualização é mostrada através de “rato sobre” (pré- -clique), e não sendo esta fulcral para a consulta, não fazia sentido considerá-la como forma de interação em dispositivos táteis – apenas é realmente funcional através da interação com rato. Contudo, esta continua útil nestes dispositivos, pois permite ver informações básicas sobre a publicação antes da visualização completa terminar de carregar.

Vista de satélite (definições do mapa)

Para reduzir custos computacionais, o website é iniciado com uma versão geométrica do mapa (Google maps) simplificada (Figura 71). Nesta, apenas é mostrada informação fundamental – os nomes dos locais e o desenho das ruas. Porém, para proporcionar um mais fácil reconhecimento dos locais, pode ser ativada uma vista de satélite no menu “Definições do mapa”. Respeitando as normas gráficas, esta vista é mostrada a vermelho (Figura 72).

88


Figura 70 - Janela de pré- -visualização

Figura 72 - Dois marcadores sobre a vista de satélite do mapa: (1) Menos zoom (2) Mais zoom

Figura 71 - Dois marcadores sobre a vista geométrica do mapa

(1) (2)

89

06. Projeto

Delimitação do chc

Para os utilizadores do adchc apenas importa visualizar o Centro Histórico de Coimbra. Por esta razão, limitou-se a navegação por arrastamento a essa zona do mapa – não é possível afastar-se demasiado do Centro His-tórico (criaram-se limites; ou segundo Norman (1988), constraints).

Foi ainda importante fazer uma delimitação visual do Centro Histó-rico para que os utilizadores pudessem perceber qual a área de interesse, pois só aí existem e podem ser feitas publicações. Esta delimitação foi feita em parceria com o Doutor Paulo Jorge Marques Peixoto, docente da Faculdade de Economia da Universidade de Coimbra, e o jacc. Para isso, considerou-se a delimitação existente feita pela Câmara Municipal de Coimbra e acres-centaram-se espaços verdes adjacentes, assim como espaços adjacentes onde se realizam atividades culturais.

Para conseguir a vista geral e completa que se pretendia, decidiu-se ini-ciar a página web mostrando toda a àrea do Centro Histórico. Isto permite ver onde existem ou não publicações, mesmo antes de desempenhar qualquer ação no mapa – uma das premissas básicas para o desenho da interface (Figura 73).

Figura 73 - Delimitação do chc através de um contorno vermelho e fundo cinza: (1) vista geométrica (2) vista de satélite

(1) (2)

90


Evolução da zona geográfica do chc e representações ilustrativas.

Com o Google Maps criou-se também uma nova possibilidade para o design da interface. O grafismo e/ou a área geográfica do mapa do Centro Histórico poderia adaptar-se consoante o intervalo de tempo pesquisado. Assim, poderíamos observar o crescimento geográfico do chc ao longo dos anos (Figura 74). Se cada grafismo/desenho fosse concebido por um artista diferente, criaríamos ainda mais uma camada de arquivo (Figura 75).

O método para alterar entre grafismos foi programado e testado rudimentar-mente. Contudo, tendo custos computacionais, não sendo trivial conseguir dados para a sua implementação, e sendo que estas não eram funcionalidades cruciais, optou-se por não as desenvolver.

(1)

(1)

(2)

(2)



91

06. Projeto

Filtragem rápida por tipo de arquivo

Apesar da visualização cartográfica ser uma excelente forma de associar uma publicação à sua respetiva localização, o elevado número de publicações poderia levar a demasiadas sobreposições e, consequentemente, uma visualização demasiado saturada. Para contornar o problema criaram-se alguns métodos de filtragem. Ao longo dos capítulos anteriores foram introduzidos alguns deles.

O primeiro foi a filtragem por tipo de arquivo – “fotográfico”, “audio- gráfico”, “videográfico” e “bibliográfico” – através do menu/logótipo. Esta é uma forma rápida de filtrar documentos que possam não ser relevantes na consulta – por exemplo, não mostrar vídeos ou mostrar apenas imagens – e pode reduzir, substancialmente, o volume de publicações no mapa.

O mesmo menu foi desenhado de forma a funcionar quase como um dropdown menu. Ao clicar ou meter o rato sobre o mesmo, todos os tipos de arquivo são mostrados – menu aberto – , sendo possível selecionar aqueles que se pretendem consultar. Feito isto, ao clicar fora ou retirar o rato sobre o menu, este apenas mostra os arquivos selecionados – menu fechado – (Figura 76). Como para abrir o menu basta colocar o rato sobre o mesmo, é necessário apenas um clique para selecionar um tipo de arquivo.

O menu/logótipo foi inicialmente caracterizado em preto. Contudo, era preciso diferenciar visualmente os tipos de arquivo selecionados dos não selecionados. Uma aparência de botão analógico, a três dimensões, poderia solucionar o problema de forma intuitiva (botão em baixo – selecionado –, botão em cima – não selecionado). No entanto, esta abordagem ia largamente contra as regras gráficas definidas para a marca. Por este motivo, construíram-se soluções alternativas.

Os tipos de arquivo selecionados mantiveram o grafismo original – pretos (como as restantes partes do logótipo), expressando uma sensação de preenchimento. Os tipos de arquivo não selecionados foram representados a branco com contorno preto, expressando a sensação de vazio.

No estado inicial do menu (ao abrir o website), todos os tipos de arquivo são automaticamente selecionados (visíveis). Isto é importante para que o utilizador entenda todas as opções disponíveis e para que, ao desselecionar, perceba qual o aspeto gráfico de uma opção selecionada versus não selecionada.

Figura 76 - Logótipo/menu apenas com o tipo de arquivo audiográfico selecionado: (1) Aberto (2) Fechado

(1)

(1)

(3)

(2)

92


Esconder os tipos de arquivo não selecionados (fechar o menu) também auxilia nesta compreensão. Isto acontece porque, ao abrir o menu, o utilizador é capaz de reconhecer e comparar o aspecto gráfico dos arquivos selecionados (mostrados no menu fechado) com os não selecionados (apenas mostrados no meu aberto). Por exemplo, se apenas está visível o arquivo audiográfico e este está representado a preto, ao abrir o menu e ver os restantes arquivos a branco, o utilizador é capaz de perceber que a opção selecionada é a opção a preto. Caso o menu estivesse sempre aberto, estando visíveis tipos de arquivo a branco e tipos de arquivo a preto, seria mais difícil perceber quais os selecionados (Figuras 76 e 77).

No estado fechado do logótipo/menu, para referir todos os arquivos, ponderou-se ainda substituir os mesmos apenas pela palavra “digital”. Porém, essa era menos clara, não tendo sido implementada.

Desenhou-se ainda um estado intermédio de seleção. Através do menu “procurar”, é possível fazer uma pesquisa mais acurada que pode devolver ape-nas parte de um tipo de arquivo. Por exemplo, uma pesquisa pode devolver duas de trinta publicações do arquivo audiográfico, nenhuma publicação do arquivo videográfico, e todas as publicações dos arquivos bibliográfico e fotográfico. No estado atual do sistema, isto levaria a que todos excepto o arquivo video- gráfico ficassem selecionados no logótipo/menu. Porém, o arquivo audiográfico não estaria a ser visualizado na totalidade. Então, de uma forma lógica, concor-dou-se que este seria caracterizado em cinza – um estado intermédio entre o branco (não selecionado) e o preto (selecionado) (Figura 78).

Contudo, não era uma certeza que este estado intermédio esclareces-se a visualização. Depois de compreendidos estes três estados de seleção, eles poderiam ser uma enorme mais valia para a visualização. Porém, sem uma explicação prévia, os mesmos poderiam ser demasiados confusos para os utilizadores. Por esta razão, tomou-se a decisão de não implementar a funcionalidade até que se tenha feedback para tal (conseguido através dos devidos testes de usabilidade a potenciais utilizadores). Não sendo implementada, o estado “não selecionado” poderá passar a representar-se a cinza, assumindo o grafismo do estado intermédio de seleção.

Figura 78 - Logótipo/menu com o tipo de arquivo audiográfico selecionado e restantes tipos de arquivo em estado intermédio de seleção (não implementado)

Figura 77 - Cronologia de dessele- ção do tipo de arquivo bibliográ-fico: (1) Logótipo/menu fechado com todos os tipos de arquivo selecionados (2) Logótipo/menu aberto com o rato sobre o tipo de arquivo bibliográfico, ainda selecionado (3) Logótipo/menu aberto com o rato sobre o tipo de arquivo bibliográfico, depois de desselecionado (4) Logótipo/menu fechado, com todos os tipos de arquivo selecionados exceto o tipo bibliográfico

(1)

(1) (2)

(3) (4)

(2)

93

Filtragem rápida por período temporal

O segundo método de filtragem, criado de raiz, foi uma timeline para selecionar publicações por data. É possível definir um limite mínimo – “de” – e um limite máximo – “até” –, escrevendo ou arrastando dois delimitadores, para visualizar um período específico. Isto permite uma consulta rápida e detalhada.

Para otimizar o espaço de visualização da interface, os delimitadores são relativamente pequenos. Contudo, ao colocar o rato sobre os mesmos, estes aumentam de tamanho sugerindo e facilitando a interação.

Devido à incongruência visual dos campos “data” nativos dos diferentes browsers, foram desenvolvidos, de raiz, campos para digitação de data nos deli-mitadores (Figura 79). Isto trouxe algumas desvantagens para a utilização mobile, pelo que, nesses suportes, se optou por continuar a utilizar campos nativos.

Figura 79 - Delimitador “até” da timeline (1) Estado normal (2) com “rato sobre” (3) Digitando o dia

(1)

(2)

(3)

06. Projeto

94


A timeline é dinâmica, e inclui sempre o período desde a primeira até a última data de produção dos documentos presentes no mapa. Por exemplo, supondo que a totalidade dos arquivos (áudio, vídeo, foto e bibliográfico) inclui o período de 2013 a 2018, ao consultar apenas o arquivo audiográfico, e supondo que este apenas inclui o período 2014 a 2016, estas datas tornar-se-ão os novos limites da timeline. Assegurando uma melhor experiência de utilização, não é possível definir datas (digitando ou arrastando os delimitadores) fora do período respetivo.

Todos anos são assinalados com um marcador vertical preto. Para evitar sobreposições e assegurar uma boa leitura, são identificados de forma escrita um máximo de 8 anos equidistantes.

Para além de no mapa, todas as publicações são marcadas na timeline. Assim, o utilizador pode perceber, antes de qualquer interação, quais as datas rele-vantes para a filtragem. Ao clicar ou colocar o rato sobre um marcador no mapa, o respetivo marcador na timeline fica a vermelho e cresce em altura, colocando-se em evidência. Em simultâneo, adapta a sua largura ao período de tempo de que trata. Por exemplo, se contém um documento produzido em 2014 e um docu-mento produzido em 2015, o marcador cresce englobando esse período. Se a publi- cação apenas contém um documento, o marcador englobará apenas o respetivo dia através de uma linha vertical (Figuras 80, 81, 82 e 83).

Figura 80 - Timeline visualizando o período de 01/12/2011 a 09/08/18

Figura 81 - Marcador da timeline em estado normal

Figura 82 - Marcadores da timeline em estado “rato sobre” (acionado colocando o rato sobre o respetivo marcador do mapa): (1) Publicações referente um dia apenas (2) Publicação referente a ao período de um mês

Figura 83 - Marcador da timeline em estado “clicado”

(1)

(2)

(3)

06. Projeto

95

06. Projeto

Inicialmente os marcadores na timeline eram interativos. O objetivo era, ao colocar o rato sobre um marcador, acionar o modo “rato sobre” no respetivo marcado no mapa. Além disso, uma publicação poderia ser aberta ao clicar no seu marcador na timeline.

Isto era uma mais valia para a visualização. Contudo, para que fosse devida-mente funcional, era preciso resolver o problema da sobreposição dos marcadores na timeline. Uma alternativa poderia passar por usar o mesmo método de expansão de marcadores desenhado para o mapa. Porém, este não permitia uma visualização temporal intuitiva. Desse modo, ponderou-se a implementação de zoom ou, em alternativa, de dispor os marcadores de forma a que não houvesse sobreposições, mas se mantivesse a leitura horizontal do tempo.

A solução desenhada consta de um método de expansão vertical dos marcadores: a timeline manter-se-ia intacta (mesma posição, tamanho, período, aspeto visual, etc.); os marcadores, manteriam a sua posição horizontal, mas se-riam empilhados caso houvesse sobreposições visuais (mesmo que as suas datas fossem diferentes). A timeline seria depois colocada sobre um fundo branco trans-parente, e poderia sobrepor totalmente o mapa, ou seja, seria trazida para primeiro plano na janela (Figuras 84 e 85).

Contudo, este método exigia demasiado tempo de desenvolvimento. Não sendo crucial, decidiu-se deixá-lo para trabalho futuros. Desta forma, permaneceu a sobreposição de marcadores na timeline.

Interagindo com os marcadores no mapa, esta sobreposição não apresenta um problema, pois o modo “rato sobre” deixa os marcadores visíveis na timeline mesmo que estejam sobrepostos (Figura 82); apenas não seria possível interagir com a totalidade marcadores na timeline (só seria possível interagir com os mar-cadores da frente). Por esse motivo, desativou-se a interação com os mesmos (só é possível interagir com os marcadores do mapa).

96


Figura 84 - Maquete do método de expansão dos marcadores sobrepostos na timeline (1 grupo expandido via “rato sobre”)

Figura 85 - Maquete do método de expansão dos marcadores sobrepostos na timeline (todos os grupos (dois) expandidos)

97

06. Projeto

Agrupamento de marcadores no mapa (definições do mapa”)

Por meio dos métodos anteriores, é possível filtrar massivamente as publicações. Porém, o fenómeno da sobreposição poderia continuar a acontecer. Por este motivo, criou-se um método de agrupamento de marcadores do mapa – clusters –, através do qual, aqueles que estejam visualmente demasiado próximos são representados por um marcador só. O mesmo é depois complementado por um número representativo da quantidade de marcadores agrupados.

Ao fazer zoom (com scroll, gesto tátil de ampliar ou clique no marcador), os marcadores deixam de estar visualmente próximos. Deste modo, deixam de estar agrupados e é possível visualizá-los normalmente.

Apesar deste método de agrupamento poder simplificar a visualização, ele apresenta vários entraves à mesma, principalmente, devido à dificuldade programacional em alterar o seu aspeto visual. Por exemplo, enquanto estive-rem agrupadas, não é possível perceber de que tratam as publicações – quais os tipos de arquivo, títulos, autores, etc. –, ou perceber se estas estão ou não aprovadas (Figura 86).

Mais uma vez, uma das premissas base do desenho da interface era que tudo estivesse, o mais possível, visível antes do utilizador ter que desempenhar qualquer ação. Por esta razão, o método de agrupamento só é ativado por vontade do utilizador, no menu “Definições do mapa”. Isto mantém, por predefinição, todas as publicações visíveis e prontas a ser abertas.

Com isto, foram já apresentadas as duas definições do mapa disponíveis – vista de satélite e agrupamento de marcadores.

Definições do mapa

Continuando a seguir a premissa referida anteriormente, o menu de defini -ções do mapa está visível e disponível sempre que possível (em algumas situações, em ecrãs menores, este menu é escondido em prol de funcionalidades indispensáveis).

Este menu está identificado com um ícone de engrenagem – um paradig-ma atual do design de interface para menus de definições –, e, à semelhança do menu/logótipo, abre ao clicar ou colocar o rato sobre o mesmo. Desta forma, com a utilização de rato, a sua utilização é bastante otimizada, sendo necessário apenas um clique para alterar definições (Figura 87).

Figura 86 - Marcadores no mapa: (1) Agrupados (menos zoom no mapa) (2) Não agrupados (mais zoom no mapa)

Figura 87 - Menu de definições do mapa: (1) Fechado (2) Aberto

98


Agrupamento e expansão de marcadores sobrepostos no mapa

Um outro fenómeno que pode acontecer no mapa é que duas ou mais publicações sejam criadas com as mesmas coordenadas geográficas, ficando perfeitamente sobrepostas. Isto faz com que não seja possível interagir com as publicações dispostas por baixo (escondidas).

Para solucionar o problema, decidiu-se agrupar estes marcadores (com ou sem o método de agrupamento ativo) e desenhou-se uma forma de os expandir através de clique ou “rato sobre”.

Permitindo adicionar um sem número de marcadores, estes seriam afas-tados em espiral desde a sua posição de origem (centróide). No entanto, estes continuariam ligados à mesma através de uma linha vermelha. Para manter a legibilidade existiria um círculo de fundo branco com alguma transparência, mantendo em mente que esta seria uma nova camada e o mapa continuaria atrás – bom mental model – (Figura 88). A expansão seria fechada ao colocar o rato fora deste círculo.

Devido à gestão de prazos de entrega, decidiu-se deixar a implementação do método de expansão para desenvolvimentos futuros, pois o fenómeno de perfeita sobreposição pode ser evitado pelos administradores da plataforma, ao aprovar, não aprovar ou editar as publicações submetidas.

Figura 88 - Maquete do método de expansão de marcadores perfei-tamente sobrepostos no mapa

99

06. Projeto

Janela de visualização de documentos

Resolvida a visualização dos marcadores no mapa e timeline, era agora importante perceber qual a melhor forma de visualizar os documentos que as constituem. Tentando alcançar um mental model (Norman, 1988) ótimo, pretendia-se que os utilizadores nunca tivessem de abandonar nem deixar de ver a página principal (mapa), qualquer que fosse a tarefa a desempenhar. Uma das abordagens para alcançar este objetivo foi já mencionada – tirar partido da transparência. Outras foram a utilização de janelas modais/ popups e o carregamento assíncrono de conteúdos.

Assim sendo, a visualização de documentos é feita numa janela modal – janela de visualização –, fruto da expansão da janela de pré- -visualização (Figura 89). Sempre que possível, esta transição acontece por meio uma animação, ajudando a perceber que uma janela é a evolução da outra e não uma janela diferente. Este é um exemplo de como a animação foi usada para ajudar o entendimento da interface.

Pelos motivos já assinalados, as janelas de pré-visualização e visu-alização são caracterizadas por alguma transparência e uma margem em redor, não tocando as margem da janela principal. Além disso, estas ocupam apenas metade da janela, ajudando a manter o mental model e a interação com o mapa (Figura 90).

A metade direita da janela foi escolhida ao invés da esquerda, pois permite que se continue a interagir com o logótipo/menu, e por ser o lado mais natural para a maioria dos utilizadores – destros –, que interagem mais frequentemente com a mão direita.

100


Figura 89 - Pré-visualização e visu-alização de uma fotografia de João Duarte: (1) Janela de pré-visualiza-ção (2) Janela de visualização

Figura 90 - Janela de visualização posicionada na metade direita da janela principal

(1) (2)

101

06. Projeto

Cabeçalho da publicação

O cabeçalho da janela de visualização herda as informações mostradas na janela de pré-visualização, à exceção do resumo/descrição dos documentos (Figura 91). Este poderia ocupar demasiado espaço na visualização. Com esta abolição, ao abrir uma publicação, é possível ver o primeiro documento e respetiva informação sem ter que fazer scroll.

Caso se pretenda voltar a ver o resumo ou saber mais informações sobre a publicação ou autores, basta clicar sobre o cabeçalho. Isto abrirá uma janela pop-up com a respetiva informação (Figura 92). Dependendo do feedback futu-ro dos utilizadores, poder-se-á manter o resumo no cabeçalho de visualização.

Aos administradores é mostrado, antes do título, o número identificador da publicação na base de dados. Isto pode ser útil caso pretendam editá-la no gestor de base de dados ou pretendam passar este número como argumento em funções do servidor. Aos utilizadores comuns, é mostrada uma versão sem número identificador (Figura 93).

Figura 91 - Cabeçalho de pré--visualização e visualização de uma fotografia de João Duarte: (1) Cabeçalho de pré-visualização (2) Cabeçalho de visualização e uma etiqueta nativa explicitando a consequência do clique (ativada colocando e mantendo o rato sobre o cabeçalho)

(1)

(2)

102


Figura 92 - Janela pop-up com informação detalhada sobre a publicação

Figura 93 - Cabeçalho sem nú-mero identificador (mostrado aos utilizadores comuns)

103

06. Projeto

Visualização dos documentos

O número de documentos numa publicação não é limitado. Por esta razão, deixar todos os documentos visíveis nesta janela poderia levar a que nenhum dos documentos tivesse leitura.

Em alternativa, ao abrir a janela de visualização, os documentos são car-regados assincronamente e dispostos em pilha (como no logótipo). Feito isto, podem ser percorridos através de scroll – um paradigma atual de interface (Figura 94).

Esta abordagem tira partido de toda a largura da janela, otimizando o tamanho da visualização dos documentos. Caso isto não seja suficiente, é possível visualizar imagens e vídeos em ecrã inteiro, clicando nas mesmas ou no botão respetivo do reprodutor de vídeo.

Seguindo as regras gráficas definidas e evidenciando os documentos, foi criado um filtro svg que tonaliza os mesmos (ou respetivos reprodutores media) de vermelho. Contudo, para que seja possível visualizá-los na sua forma original, o filtro é removido se o rato estiver sobre os mesmos (Figura 95).

Para que o utilizador não seja importunado por informação que não necessita, apenas são mostrados os documentos cujo tipo de arquivo tenha sido requerido. Por exemplo, se uma publicação tem documentos de imagem, áudio, vídeo e texto mas o utilizador apenas pesquisou no arquivo audiográfico, ao abrir a publicação apenas são mostrados os documentos áudio. Se for do seu interesse ver todos os documentos da publicação, é-lhe oferecida a possi-bilidade de o fazer, clicando no botão “ver publicação completa” (Figura 96).

Figura 94 - Cronologia exempli-ficativa da navegação na janela de visualização de documentos (scroll): (1): Texto seguido de imagem (parcialmente visível); (2) Imagem (totalmente visível depois de fazer scroll)

104


Figura 95 - Rato sobre imagem (imagem sem filtro e uma etiqueta nativa, dando a entender qual será a consequência do clique)

Figura 96 - Janela de visualiza-ção na metade direita da janela principal; Botão “Ver publicação completa” substituindo os docu-mentos cujo tipo de arquivo não está selecionado (neste caso o tipo de arquivo fotográfico); Botão “Eliminar publicação” imediata-mente por baixo

Figura 97 - Janela pop-up nativa para confirmação o eliminar de uma publicação

105

06. Projeto

Caso comecem a existir publicações demasiado longas, pretende-se implementar um sistema de carregamento progressivo de documentos. Isto é, carregar os mesmos à medida que o utilizador faz scroll na janela de visualização (só são carregados quando estão prestes a ficar visíveis na janela).

Caso a publicação pertença ao utilizador com sessão iniciada, é ainda mostrado um link “Eliminar publicação” que permite eliminar definitivamente a publicação. Para evitar que o utilizador clique por engano, este link é mos-trado no final de todos os documentos de uma forma discreta. Além disso, ao clicar no mesmo é ainda mostrada uma janela de confirmação (Figura 97).

Ponderou-se ainda criar um método de edição de publicações para qualquer utilizador com sessão iniciada, que permitiria acrescentar ou alterar documentos e/ou cabeçalhos. Sendo que todas as alterações teriam de ser apro-vadas pelo jacc, um utilizador poderia corrigir ou complementar publicações de outros utilizadores (publicações colaborativas). Porém, devido a questões de gestão temporal, esta tarefa não foi concretizada. Isto não apresenta um problema pois, caso haja um erro não detetado pelo jacc, o utilizador pode contactar o mesmo ou eliminar a publicação e submeter uma versão corrigida.

Figura 98 - Ícone de download por Google. Retirado de iconfinder.com/icons/326639/download_file_icon

Figura 99 - Ícone de download, legenda e etiqueta nativa mos-trando a descrição completa de um campo (ativada colocando e mantendo o rato sobre os campos)

Figura 100 - Janela pop-up nativa com informação sobre um documento, ativada clicando na respe-tiva legenda

106


Legenda e download de documentos

Um documento é sempre seguindo de um botão para descarregar e uma legenda. O botão de descarregar é identificado pelo ícone de download utilizado pela Google (naturalmente interpretável) e permite descarregar imagens, vídeos ou sons no seu formato original, e textos em formato pdf (Figura 98).

Na legenda é indicado o título do documento, autores, data de publi-cação, data/período de produção e licença Creative Commons (ícone). Colocar e manter o rato sobre estes campos mostra uma etiqueta com uma descrição mais detalhada dos mesmos. Isto é útil caso estes estejam simplificados com reticências por falta de espaço, pois a etiqueta permite ler a descrição com-pleta (Figura 99). Clicar sobre a legenda abre uma janela pop-up com toda a informação do documento (Figura 100).

Colocar e manter o rato sobre o ícone identificador da licença Creative Commons mostra uma etiqueta nativa com a descrição respetiva (Figura 101). Clicar sobre o mesmo abre a respetiva página web (de creativecommons.org) numa nova janela, onde se podem ler os termos de uso associados (Figura 102). Cada documento pode ser usado consoante a respetiva licença.

Figura 101 - Etiqueta nativa explicativa do tipo de licença, ativada colocando e mantendo o rato sobre o respetivo ícone

Figura 102 - Página web Creative Commons oficial, explicativa do tipo de licenta cc by-nc 4.0: creati-vecommons.org/licenses/by-nc/4.0

107

06. Projeto

Coleções

Uma publicação pode estar associada a outras publicações através de uma coleção – um grupo de publicações referentes a diferentes localiza-ções, mas que não faz sentido separar, pois podem ler-se em continuidade. Por exemplo, uma série de entrevistas a músicos da Baixa, no âmbito de um determinado programa.

As coleções são também uma das principais razões para que as publi-cações sejam visualizadas apenas em metade da janela. Isso permite manter a interação com o mapa, sendo possível alternar entre publicações da mesma coleção.

As coleções são visualizadas tirando partido de dois métodos. O pri-meiro é desativar todos os marcadores não referentes à coleção da publicação selecionada – ficam com contorno a cinza e não é possível interagir com eles. Os restantes marcadores – da mesma coleção – mantêm-se ativos. Para enfatizar a sua interligação e, se pretendido, criar um percurso lógico de visualização, todos os marcadores referentes à mesma coleção são ligados, dois a dois, por uma linha vermelha. Esta é ainda acompanhada pelo nome da coleção (Figura 103).

Numa fase inicial, esta linha terminava com uma seta e conectava os marcadores por data de início de produção do primeiro documento da publi- cação. Desde aí, a programação do arquivo sofreu alterações suficientemente drásticas para que essa ordenação tivesse de voltar a ser desenvolvida. Porém, por questões de gestão do tempo útil, e dado que esta não era uma funcionalidade crucial, o seu redesenvolvimento foi deixado em segundo plano. Assim, os marcadores são agora ligados por ordem de publicação.

Caso uma coleção inclua publicações que apenas pertençam a arquivos não selecionados, estas publicações não serão mostradas ao visualizar coleção (para ver toda a coleção o utilizador deve selecionar os restantes tipos de arquivo). Deste modo, ponderou-se o desenvolvimento de um botão para devolver automaticamente toda a coleção, caso esta não estivesse a ser visualizada na totalidade. Este botão poderia localizar-se na janela de visualização ou poderia ser a própria legenda (nome da coleção) no mapa. Contudo, também devido a questões de gestão do tempo útil, e dado que esta não era uma fun-cionalidade crucial, esta foi deixada para trabalho futuro.

É possível ativar e desativar a visualização de coleções, clicando no nome da coleção presente no cabeçalho de uma publicação (Figura 104). Assim, continua a ser possível interagir com publicações de outras coleções, sem que seja necessário fechar a publicação aberta.

108


Figura 103 - Três publicações conectadas numa coleção (publi-cação do meio, aberta) pela linha vermelha. As restantes publica-ções, a cinza, foram desativadas

Figura 104 - Método de ativação e desativação da visualização de coleções: (1) Coleção ativada (pre-definição); (2) Coleção desativada

(1)

(2)

109

06. Projeto

Menus laterais

A plataforma conta ainda com uma série de menus laterais – “procura”, “lista”, “publicar”, “perfil”, “apps” e “sobre” –, escolhidos em consenso com o jacc . A disposição e aspeto gráfico dos mesmos inspira-se nos ficheiros e respetivos separadores falados no subcapítulo anterior – os menus são “arquivados depois da margem direita da janela, ficando ape-nas visíveis as etiquetas com os seus nomes. Os mesmos foram ordenados, de cima para baixo, por potencial frequência de utilização e relação lógica (menu de pesquisa junto da lista de publicações devolvidas, menu de publicação junto do menu de perfil, etc.).

Para enfatizar o motivo gráfico e dar a entender a ação inerente a clicar nas etiquetas, se o rato estiver sobre as etiquetas, o menu abre subtilmente, deslocando-se alguns pixels em direção ao centro da janela. O deslocar hori-zontal de menus é um paradigma de design de interface atual (principalmente em dispositivos móveis) e é outro exemplo de como a animação foi usada para melhorar o entendimento da interface (Figura 105).

Ao clicar nas etiquetas, o respetivo menu é aberto, ou seja, desloca-se da margem direita (fora da janela) até ao centro do ecrã (dentro da janela). Pelo mesmo motivo da janela de visualização, os menus laterais ocupam apenas a metade direita do ecrã. Para contrastar com a janela principal e se diferen-ciarem da janela de visualização, optou-se por caracterizar os mesmos com um fundo preto. Assim sendo, os textos e restantes elementos a preto passam a branco (Figura 106).

O conteúdo dos menus foi disposto de uma forma balançada entre ter o máximo de informação visível na janela, e esconder informações menos frequentemente utilizadas para não causarem ruído.

Se necessário, o conteúdo dos menus pode ser percorrido através de scroll. Porém, para que o utilizador saiba sempre onde está na plataforma (bom mental model), o título de cada menu mantém-se fixo no topo do mesmo. Estes títulos são uma explicação alongada da respetiva etiqueta. Por exemplo, à etiqueta “procurar” corresponde o título “procurar NO ARQUIVO”.

Caso exista um formulário e este contenha campos de preenchimen-to obrigatório, começa-se por mostrar uma nota indicando qual a forma de reconhecer os mesmos. Identificá-los com um asterisco é um standard frequentemente utilizado. Por essa razão, utilizou-se esse método.

110


Figura 105 - Menus laterais (lado direito da janela principal): (1) Todos os menus no seu estado pré-definido (2) Rato sobre a etiqueta do menu “perfil”

Figura 106 - Menu lateral “perfil” aberto, ocupando a metade direita da janela

Contudo a sua visibilidade é reduzida, o que pode levar o utilizador a falhar campos. Por essa razão, a obrigatoriedade dos campos foi reforçada, pintando o seu fundo de vermelho. Isto pode ser visto rapidamente sem um grande esforço do utilizador, agilizando a interação.

O preenchimento dos campos obrigatórios é automaticamente verifi-cado do lado cliente antes da submissão dos formulários. Isto agiliza a intera-ção, pois o utilizador é avisado dos campos em falta sem ter que esperar uma resposta de erro do servidor.

Os formulários podem ser enviados, clicando no respetivo botão de submissão ou premindo a tecla ENTEr. Este último método apenas é permi-tido se o utilizador estiver a digitar no último campo do formulário ou não estiver a digitar em nenhum campo. Tomou-se esta decisão para evitar que o formulário fosse submetido por engano, assim como permitir que a mesma tecla fosse usada para acionar funções de automáticas de preenchimento. Por exemplo, se o utilizador escrever o nome de uma rua no campo “Rua ou zona” e premir ENTER, o sistema preenche de imediato o campo “Coordenadas” com a latitude e longitude respetivas.

(1) (2)

111

06. Projeto

Procura no arquivo

O logótipo/menu e timeline são formas limitadas de procurar na interface. Por este motivo, o primeiro menu lateral é um menu de procura detalhada, etiquetado por “procurar”. Aí é possível filtrar publicações pelas mais diversas características, tais como: tipo de arquivo; palavras-chave; palavras no resumo; título ou autor da publicação, documento ou coleção; entidade detentora e espólio do documento; data (e/ou hora) ou período de publicação do documento; data (e/ou hora) ou período de produção do documento; data (e/ou hora) ou período de criação da coleção; rua/zona ou coordenadas geográficas da publicação; raio de procura com centro na mesma localização.

Caso o utilizador já tenha feito login, pode ainda filtrar apenas as suas publicações e/ou publicações por aprovar. Pretende-se ainda implementar as opções: “apenas não publicado por mim” e “apenas aprovado”. Porém, sendo elas menos úteis, decidiu-se deixar esta tarefa para trabalho futuro.

O utilizador pode ainda indicar a rua/zona e raio de procura intera-gindo com um marcador circular especialmente desenvolvido para o efeito (Figura 107). Este aparece no mapa ao clicar no botão “Escolher coordenadas no mapa”, digitando uma rua ou coordenadas, ou alterando o raio de procura. Digitar o nome de uma rua preencherá automaticamente o campo coorde-nadas e vice-versa.

Figura 107 - Marcador (vermelho, redondo) para seleção de uma localização e raio de procura no

Figura 108 - Menu lateral “procurar” aberto: (1) Sem sessão iniciada, com campos escondidos (predefinição); (2) Com sessão iniciada, com campos escondidos; (3) Com sessão iniciada, sem campos escondidos (1)

112


Caso esteja no Centro Histórico de Coimbra, o utilizador pode tam-bém utilizar o botão “Usar a minha localização” para definir o nome da rua e respetivas coordenadas através da informação de rede e GPS do seu dispositivo.

Dada a quantidade de parâmetros e sendo que alguns deles podem ser mais frequentemente usados que outros, este menu é iniciado mostrando apenas uma seleção de campos pré-definida – palavras-chave, título da publi-cação, título do documento, título da coleção, data (e/ou hora) ou período de produção do documento, rua/zona e raio de procura. Também o botão “Usar a minha localização” é escondido nesta pré-seleção.

Para abrir os restantes campos foi criado um botão “Ver mais parâme-tros de pesquisa”, que serve igualmente para os voltar a esconder (“Ver menos parâmetros de pesquisa”).

Por fim, foi criado um botão “Repor todos os campos” que serve para repor todos os campos em branco. Uma procura nestes termos retornará todas as publicações de todos os tipos de arquivo.

Alguns dos campos são preenchidos por predefinição com frases expli-cativas do tipo de informação a inserir – placeholders. Por exemplo, o campo “Rua ou zona” é preenchido com “Dê-nos a rua, nós damos as coordenadas”. Estas frases são caracterizadas a cinzento, pois este é um standard atual para placeholders (Figura 108).

(2) (3)

113

06. Projeto

Listagem das publicações

As visualizações cartográfica e temporal apresentam limitações caso se pre-tenda visualizar ou pré-visualizar as publicações uma a uma, ou ter um olhar rápido sobre os títulos existentes. Por este motivo, o menu que se segue, eti-quetado por “lista”, é uma listagem de todas as publicações pesquisadas (du-plicados de todas aquelas que estiverem no mapa/timeline). Estas são repre- sentadas pelo respetivo título envolto num quadrilátero, mantendo a ana-logia com os marcadores do mapa e sugerindo a mesma forma de interação. Para reforçar ainda mais esta ligação entre duplicados, o rato sobre um marcador no mapa ativa o estado “rato sobre” do seu duplicado na lista e vice-versa.

É possível organizar a listagem por quatro tipos de parâmetro – coleção, ano de produção, ano de publicação e nome do publicador. Isto é feito esco--lhendo uma de quatro opções presentes no topo do menu, em “Organizar por”. Ao escolher uma delas, a anterior é desselecionada e é implementada a respetiva organização, não sendo necessário desempenhar qualquer tipo de confirmação ou submissão. Desta forma, para organizar a lista basta apenas um clique.

A organização é feita separando as publicações em grupos, identificados por um respetivo título. Por exemplo, organizando por ano de produção, os títulos poderiam ser “2011”, “2013”, “2017”, etc., ou organizando por nome do publicador, os títulos poderiam ser “Pedro Martins”, “João Bicker”, etc.

Em cada grupo, as publicações são dispostas em blocos de linhas, permitindo uma otimização máxima do espaço. Assim, é possível visualizar o máximo de publicações sem ter que recorrer ao scroll (Figura 109).

Apesar de ser possível filtrar as publicações “por aprovar” no menu “procurar”, no decorrer do desenvolvimento decidiu-se implementar uma opção para organizar publicações por estado de aprovação. Esta seria mais uma forma de consultar publicações aprovadas versus por aprovar. No entanto, mais uma vez devido à gestão temporal e não sendo uma funcionalidade crucial, decidiu-se implementá-la em trabalho futuro.

114


Figura 109 - Menu lateral “lista” aberto: (1) Publicações organizadas por coleção (2) Publicações orga-nizadas por ano de produção; rato sobre uma publicação e respetiva pré-visualização

(1)

(2)

115

06. Projeto

Publicar no arquivo

Um dos principais requisitos do projeto era que a plataforma permitisse a colaboração dos utilizadores. Estes poderiam ser utilizadores comuns ou cola- boradores do jacc. Nestes últimos enquadram-se, por exemplo, alunos e professores do curso de Sociologia da Faculdade de Economia da Universidade de Coimbra, que participam já no projeto, recolhendo, tratando, estudando e inserindo docu-mentos. Assim sendo, o próximo menu construído, etiquetado por “publicar”, foi o menu para criar e carregar publicações.

Neste menu existem campos de preenchimento obrigatório: título da publicação, resumo da publicação, latitude e longitude (o utilizador pode apenas digitar o nome de uma rua/zona e estes campos são automaticamente preenchidos), um documento (ficheiro ou texto) e respetiva data de produção.

Definir ou não uma licença de uso de um documento é igualmente obri-gatório. Contudo, esta é preenchida por omissão como “Não permitir adap-tações nem uso comercial (Creative Commons Atribuição 4.0 Internacional).

Além destes, existem também campos de preenchimento não obrigatório: palavras-chave, rua ou zona, coleção, título do documento, autor do documen-to, entidade detentora do documento, espólio do documento, hora (de e até) de produção do documento, período de produção do documento. É possível, mas não obrigatório, carregar mais do que um documento numa publicação.

A plataforma conta com uma página de termos de uso e publicação. Contudo, é raro o utilizador que os lê. Desse modo, assegurando que todos os campos são preenchidos da devida forma, foram criadas algumas notas explica-tivas ao longo do menu. Por exemplo, o termo coleção pode ser interpretado de várias formas pelos utilizadores. Então, este campo é acompanhado de uma breve descrição, explicativa do cenário em que várias publicações devem pertencer a uma coleção. O mesmo acontece, por exemplo, com o tipo de ficheiros que podem ser carregados – “Pode carregar ficheiros jpg, png, gif, svg, mp3, mpeg, ware, mpa ou mp4 até 250Mb”.

Neste menu é possível definir os campos “Rua ou zona” e “Coordenadas do conteúdo” através dos mesmos métodos descritos para o menu “procurar”.

É possível carregar ficheiros de imagem, vídeo ou áudio, ou redigir textos diretamente na plataforma. Os textos podem ser redigidos ao usar o botão “Redigir texto”. Os restantes tipos de ficheiro são carregados clican-do no botão “Carregar ficheiro”, o que abre uma janela pop-up nativa para escolher um ficheiro do dispositivo, ou arrastando-os para cima do mesmo.

116


Desta forma, simplificou-se a interação, não sendo necessário fazer qualquer tipo de discriminação prévia.

Os campos respetivos aos documentos (título, autor, entidade deten-tora, etc.) apenas são mostrados depois de ter sido carregado um ficheiro ou ter sido clicado o botão “Redigir texto”. Isto evita a exibição de informação desnecessária, e que o utilizador tente submeter uma publicação sem ficheiros. Junto com cada documento é mostrado um botão para o excluir/eliminar – “Excluir este documento”.

Os documentos e respetiva informação são agregados por módulos/contentores, quadriláteros, com uma cor suficientemente diferente da cor de fundo do menu. Isto visa facilitar a associação dos campos ao seu documento respetivo.

Ao carregar um ficheiro ou clicar o botão “Redigir texto” é ainda criado um novo módulo, abaixo do anterior, com as opções de carregamento iniciais – “Carregar ficheiro” e “Redigir texto”. Aí pode ser carregado um novo ficheiro/texto, que terá associados os seus próprios campos “Título”, “Autor”, “Entidade detentora”, etc.

Como referido, os textos são redigidos diretamente na plataforma ao invés de carregados em ficheiros de texto (txt, RTF, etc.). Igualmente, não é permitida a inserção de ficheiros pdf, DOCS, etc. pois pretende-se a exibição de ficheiros singulares e não de composições texto-imagem e/ou com um layout próprio. Contudo, os textos redigidos e carregados na plataforma podem ser descarregados em formato pdf.

Ponderou-se a limitação do número de documentos carregados. No entanto, tomou-se a decisão de não a implementar, pois esse trabalho poderá ser feito pela equipa do jacc, aprovando, não aprovando ou editando publicações. Implementou-se, porém, um limite de 250Mb para o tamanho dos ficheiros carregados. Isto previne o sobrecarregar do servidor. Como com os campos obrigatórios, este limite é previamente controlado do lado cliente, evitando mensagens de erro do servidor.

Para cada documento existe um botão “Usar data e hora atuais” que preenche automaticamente o campo “Data de produção” com a data e hora atual do sistema. De igual modo, no menu “procurar” foram criados os devidos limites para a inserção de datas (Figura 110).

117

06. Projeto

(1) (2)

(3) (4)

118


Figura 110 - Menu “publicar” aberto: (1) vista predefinida: rato sobre botão para redigir texto (2) Formulário para documento de texto, aberto ao carregar no mesmo botão (3) Rato sobre botão para carregar ficheiro (4) Janela pop-up nativa para selecionar um ficheiro do dispositivo, aberta ao carregar no mesmo botão (5) Carregar um ficheiro através de arrastamento (alternativa a clicar no botão “Carregar ficheiro” (6) Formulário para documento Imagem, aberto ao selecionar um ficheiro na janela pop-up; pré- -visualização da imagem selecio-nada (7) O mesmo formulário e os botões para submissão da publi- cação (“enviar para aprovação”) e repor todos os campos em branco (“Repor todos os campos”); (8) Janela pop-up nativa pedindo confirmação para a submissão da publicação

(1)

(5) (6)

(8)

(7)

119

06. Projeto

Aprovação

Como referido anteriormente, as publicações submetidas precisam sempre de ser aprovadas pelo jacc antes de serem visíveis para os restantes utilizadores. Isto é possível graças à distinção de contas de utilizador, feita na base de dados – “programador”, “jacc”, “equipa oficial do jacc” e “utilizador comum”. Esta distinção serve para diferenciar ações permitidas na interface: utilizadores com con-ta “programador” ou “jacc” podem ver, aprovar, reprovar ou editar publicações; utilizadores com conta “equipa oficial do jacc” podem realizar o mesmo tipo de ações que os utilizadores comuns, tendo a vantagem de que as suas publicações podem ser consideradas prioritárias na lista de publicações por aprovar.

Aprovar ou reprovar publicações pode ser feito diretamente na plata-forma através dos botões “aprovar” ou “eliminar”, encontrados depois do último documento de cada publicação por aprovar. Optou-se por etiquetar o botão de reprovação com a palavra “eliminar” ao invés de “reprovar”, para que fosse claro que a publicação é realmente eliminada e não guardada como “não aprovada”.

Ponderou-se desenvolver uma interface backoffice para visualização e gestão de publicações. No entanto, não era possível realizar essa tarefa em tempo útil. Por esta razão, foi criado ainda um botão “EDITAR NO MYADMIN” que abre o gestor de base de dados numa nova janela. Aí o jacc pode iniciar sessão com os devidos dados e editar qualquer informação à excepção daquelas que forem referentes à tabela de palavras-passe. A restrição de acesso a esta tabela era importante para garantir que a integridade de palavras-passe, salts, etc. não era comprometida.

Assim como o contorno dos marcadores de publicações por aprovar, também o contorno da janela de visualização de publicações por aprovar é tracejado, mantendo a analogia. A Figura 111 refere a janela de visualização de uma publicação por aprovar e respetivos botões.

Figura 111 - Janela de visualização de uma publicação por aprovar

120


Carregamento, alojamento, e visualização de documentos através de serviços externos

Inicialmente definiu-se como implementação extra o carregamento, aloja-mento e visualização de documentos através de serviços externos como as apis do YouTube, SoundCloud e Flickr, etc. O objetivo era que os documentos carregados e aprovados na plataforma fossem também carregados automaticamente para estes serviços (numa conta do adchc), facilitando a dinamização do adchc nas redes sociais.

Ponderou-se ainda possibilidade dos documentos ficarem guardados apenas nos servidores dos mesmos serviços, sendo apagados do servidor do adchc. Quando necessário, as apis seriam novamente utilizadas para trazer os documentos de volta à plataforma (na janela de visualização). Isto pouparia grandes quantidades de espaço. Contudo, esta alternativa impossibilitava o download de alguns tipos de documento. Por exemplo, o YouTube não permite o download de vídeos. Por esta razão, os ficheiros continuariam a ser carregados em duplicado (no servidor do adchc e dos serviços externos).

A api do YouTube teria ainda a vantagem de poder proporcionar a inser- ção de vídeos em direto na plataforma. Esta funcionalidade poderia ser útil para que o jacc pudesse transmitir e publicitar eventos relevantes. Por exemplo, uma feira cultural na baixa.

Outras dificuldades se encontraram com a api do SoundCloud que não permitia registar novas aplicações devido ao excesso de pedidos. Depois de procurar alguns serviços equivalentes, encontrou-se um que talvez se adap-tasse às necessidades – a api do Audiomack. A versão disponível ao público não permitia o upload e download de ficheiros. Porém, depois de entrar em contacto com os responsáveis pelo serviço, estes cederam uma versão beta da api com a qual já era possível.

As implementações das apis do Youtube, Flickr e Audiomack foram ini-ciadas. Foi implementado um script de carregamento automático de ficheiros, e uma forma de visualizar os respetivos vídeos na plataforma. Contudo, devido a questões de gestão temporal, ficou por concretizar um método para definir a conta de YouTube do adchc como pré-definição, e manter a respetiva sessão iniciada. Pela mesma razão, quanto ao Flickr, foi desenvolvido apenas o método para visualização de fotografias na plataforma e quando ao Audiomack, optou-se por parar os trabalhos ainda em fase de testes (não sendo estas funcionalidades cruciais, não de justificava despender o tempo que estas ainda necessitavam).

121

06. Projeto

Perfil de utilizador

No menu etiquetado por “perfil”, é possível desempenhar todas as ações relacionadas com o perfil de utilizador – criar um perfil, fazer login, recuperar palavra-passe e editar perfil. Estas ações são visualizadas individualmente.

O estado inicial do menu é um formulário para login (iniciar sessão). Este é constituído por dois campos, ambos de preenchimento obrigatório – “Nome de utilizador ou e-mail” e “Palavra-passe” –, seguidos de um botão de submissão – “entrar”. É possível fazer login com ambos: nome de utilizador ou e-mail. Isto facilita a interação pois cada utilizador pode utilizar aquele que lhe for mais cómodo ou fácil de memorizar (Figura 112).

Caso o utilizador ainda não tenha conta, depois do mesmo botão, existe um botão “Criar uma conta” que esconde o formulário de login e mostra um formulário para criação de conta, na mesma janela. Este formulário tem como campos obrigatórios “Nome a exibir (pessoal ou organização)”, “Nome completo (pessoal)”, “Data de nascimento (pessoal)”, “Nome de utilizador”, “E-mail”, “Palavra-passe” e “Repetir palavra-passe”.

Através da coexistência dos campos “Nome a exibir (pessoal ou organiza-ção)” e “Nome completo (pessoal)” é possível criar um perfil em nome de uma organização mas continuar a relacionar o perfil a um utilizador singular. Isto é importante pois ajuda a equipa do jacc a assegurar a credibilidade do perfil.

Figura 112 - Menu lateral “perfil” aberto - formulário de login

122


Para além de também sustentar a tarefa anterior, o campo “Data de nascimento (pessoal)” ajuda a assegurar que os utilizadores registados são maiores de idade (foram criados limites mínimo – 18 anos – e máximo – 150 anos).

Nos campos para inserção de palavras-passe não é possível reconhecer visualmente os caracteres inseridos. Assim, obriga-se à repetição da palavra--passe, o que ajuda a garantir que o utilizador não se enganou ao inseri-la.

O formulários de criação de conta tem como campos não obrigatórios “Morada”, “Sobre”, “Telemovel / telefone”, “Website” e “Facebook”, que devem ser preenchidos em relação à entidade indicada no campo “Nome a exibir (pessoal ou organização)”. Isto é explicitado numa nota que antecede os mesmos campos.

Poder recuar no estado de um sistema é uma prática essencial para conseguir uma boa experiência de utilização. Por esta razão, foi criado um botão “Voltar ao login”, que volta a esconder o presente formulário e mostra o formulário de login (Figura 113).

Figura 113 - Menu lateral “perfil” aberto - formulário de criação de perfil/conta

123

06. Projeto

Voltando a este último – o formulário de login (Figura 1) –, junto ao botão de submissão, existe uma hiperligação para redefinição da palavra-passe. Isto é útil caso o utilizador tenha já criado um perfil mas se tenha esquecido da palavra-passe. Assim como no botão “Criar conta”, clicar nesta hiperligação esconderá o formulário de login e mostrará o formulário para redefinição de palavra-passe, na mesma janela.

Esse formulário é constituído por um campo “Email associado à conta”, um botão de submissão e uma nota explicativa de como a palavra-passe será redefinida – “Enviar-lhe-emos o link de uma página onde poderá redefinir a palavra-passe”. À semelhança do menu de criação de perfil, também aqui existe um botão para recuar (Figura 114).

Ao fazer login com sucesso, é mostrada uma janela pop-up felicitando o utilizador e explicitando a forma gráfica de identificar que o login está ativo (Figura 115). Essa forma, visível da janela principal, distingue a etiqueta “perfil”, pintando os seus contornos a vermelho. Ao mesmo tempo, o formu-lário de login é substituído por um formulário semelhante ao de criar perfil, preenchido com as informações que o utilizador forneceu previamente.

Para além do menu de perfil, ponderou-se exibir o nome do utilizador no canto superior direito da janela principal (junto ao menu de definições do mapa). Contudo, não sendo frequentemente útil, essa informação poderia cau-sar ruído desnecessário na interface. Por essa razão, isto não foi implementado para já. Caso o feedback futuro dos utilizadores revele a sua utilidade, poderá vir a ser concretizado.

Sendo que é necessário submeter e confirmar a edição de perfil (não há risco de edição por engano), as informações do utilizador são diretamente dispostas num formulário editável (em vez de texto não editável e um botão para editar). Isto agiliza o processo de edição.

A diferença entre o formulários de perfil e criação de perfil é apenas nos campos de inserção de e-mail e palavra-passe . O primeiro – para inserção do e-mail – difere por ser o único campo não editável. Isto acontece para assegurar que o utilizador mantém uma identidade credível – cada conta criada estará sempre associada ao mesmo endereço de e-mail. Os últimos – para inserção de palavra-passe – foram substituídos por um botão “Alterar palavra-passe” (Figura 116), que substitui o formulário de criação de perfil por um novo formulário para alteração de palavra-passe, na mesma janela.

124


Figura 114 - Menu lateral “perfil” aberto - formulário de recuperação de palavra-passe

Figura 115 - Janela pop-up nativa indicando que a sessão foi iniciada com sucesso e qual a forma de identificar, rapidamente, que a sessão contínua iniciada

Figura 116 - Menu lateral “perfil” aberto - formulário de informações de perfil

125

06. Projeto

Este novo formulário – para alteração da palavra-passe – é constituído por três campos, todos eles obrigatórios – “Palavra-passe atual”, “Nova palavra- -passe” e “Repetir nova palavra-passe” –, assim como um botão de submissão. Os campos referidos são transportados para este formulário para evitar informação pouco utilizada. Seguindo os mesmos princípios, existe um botão para voltar ao formulário anterior – “Voltar ao perfil” (Figura 117).

À direita do botão “Alterar palavra-passe” – no formulário de perfil (Figura 116) – existe uma hiperligação através da qual é possível eliminar a conta com a qual se fez login. Assim como em “Eliminar publicação”, optou-se por uma hiperligação ao invés de um botão, para que esta estivesse presente de uma forma discreta – pretende-se que esta seja a funcionalidade menos utilizada na plataforma.

Para que o utilizador não preencha o formulário de eliminar conta por engano, ao contrário dos anteriores, este é aberto numa nova janela. Aí é permitido escolher entre duas modalidades devidamente explicitadas na mesma janela. Por predefinição, eliminar uma conta apenas elimina os dados pessoais do utilizador e mantém as suas publicações. Estas passam a ser iden-tificadas como tendo sido publicadas por um utilizador desconhecido. Esta ação mantém o nome de utilizador e palavra-passe inalterados, sendo possível continuar a fazer login com a conta (recuperar a conta).

Ao selecionar a opção “Eliminar conta e publicações”, a conta e res-petivas publicações são eliminadas da base de dados definitivamente. Esta é uma ação sem retorno possível, sendo isto clarificado mais do que uma vez, inclusivé, junto da mesma opção.

Por motivos de segurança, garantindo que a conta é apagada delibera-damente e apenas pelo seu criador, é requerido que se digite a palavra-passe da conta num campo respetivo. Só depois é possível eliminar a conta com sucesso, clicando no botão “Eliminar conta”. Igualmente, esta ação termina a respetiva sessão (Figura 118).

Também por motivo de segurança, no menu “perfil” assim como em todo o website, os campos para inserção de palavra-passe são encriptados do lado cliente (algoritmo sha-512) antes de serem enviados para o servidor (Figura 119). Além disso, todos os formulários com informação crítica (infor-mação dos utilizadores) são enviados através do método POST. Isto garante que os dados viajam encriptados na rede e não são visíveis no url.

126


Figura 117 - Menu lateral “perfil” aberto - formulário de alteração de palavra-passe

Figura 118 - Página para eliminar conta no adCHC

Figura 119 - Palavra “exemplo” encriptada com o algoritmo sha-512

4034f003d2a36cc687ebc550a8223ae09Bba9e7a4986419c72324dbebb8d1a9632Bf1e79ed3d0729b6379b109d20793acb2eFf87bd764d5914d3ab0516aa8ebc

127

06. Projeto

api e aplicações externas

A consulta e utilização dos documentos era um requisito já resolvi-do através da janela de visualização e botões de descarregar. Contudo, estes métodos poderiam ser limitados para o desenvolvimento de aplicações dinâmicas ou que envolvessem a utilização de muito documentos. Assim, foi desenvolvido uma api para aceder à informação e documentos do arquivo.

O menu etiquetado por “apps”, é uma galeria para divulgação de apli-cações, websites, instalações, etc. que tenham sido construídas tirando partido desta api. O mesmo menu começa com uma nota, convidando os utilizadores a utilizar a api e mantendo em mente que a utilização de cada documento é permitida de acordo com a respetiva licença. Esta nota contém um link direto para a documentação da api. De seguida, é mostrada uma lista de aplicações/websites (empilhadas) submetidas por utilizadores e aceites pela equipa do jacc. Estas são caracterizadas por um ícone quadrado, título, descrição e tipologia – website, aplicação, etc. Tudo isto é agrupado num módulo e, conjuntamente, forma uma hiperligação que direciona para um endereço web respetivo (web site, appstore, etc.). Esta hiperligação é evidenciada sublinhando a informa-ção da aplicação (paradigma para links) (Figura 120), e pintando o fundo do módulo de vermelho sempre que o rato está sobre o mesmo (Figura 121).

Como descrito na página de documentação da api, a submissão de aplicações é feita através de um pedido via e-mail, onde devem constar as informações acima descritas. Como trabalho futuro, se a utilização da api for recorrente, pondera-se a criação de um formulário de submissão para as aplicações criadas.

Para demonstração da api, foi desenvolvida uma aplicação (página web) onde uma imagem retirada dinamicamente do arquivo é deformada pelos valores de amplitude analisados de um som do arquivo. Apesar deste também poder ser acedido e reproduzido via api, o som foi previamente descarregado da plataforma através do respetivo botão de download. Desta forma, demonstra-se numa só aplicação, ambos os métodos de acesso aos documentos (Figura 122).

128


Figura 120 - Menu lateral “apps” aberto

Figura 121 - Rato sobre a hiperli-gação de uma aplicação no menu lateral “apps”

Figura 122 - Aplicação web desenvolvida com a api do adchc. Disponível em student.dei.uc.pt/ ~dfl/murmur

129

06. Projeto

Contactos e informação sobre o adchc

Por último, no menu etiquetado por “sobre” consta uma descrição do que é o adchc, os contactos respetivos e um link para os termos de uso e privacidade do site (Figura 123).

Sugestões automáticas

Os menus ”procurar” e “publicar”, descritos anteriormente, constatam com um método capaz de retornar sugestões automáticas de preenchimento. Agilizando a velocidade de resposta do mesmo, e oferecendo uma rápida visualização das respostas por parte do utilizador, é devolvido um máximo de 6 sugestões.

O método mostra em tempo real, por baixo do respetivo campo, as opções existentes no arquivo que vão de acordo com o que utilizador tenha escrito. Isto é, se o utilizador escreveu a palavra “mãe” no campo título, o método irá devolver títulos de publicações onde conste a essa palavra. Por exemplo, “Mãe anda cá ouvir, é bué fixe!” (Figura 124).

Se for o caso de não existir nenhuma publicação que corresponda, é mostrada apenas uma mensagem elucidando disso – “Não existem publi-cações que correspondam”. Isto permite agilizar a pesquisa, pois se o método não devolver sugestões, sabe-se à partida que não serão devolvidas publica- ções na pesquisa (Figura 125).

Igualmente, isto permite verificar se já existem publicações com o mes-mo nome do que aquela que queremos submeter. Caso existam, é mostrada uma janela pop-up, alertando para esse facto. Através da mesma, é possível filtrar no mapa todas as publicações com nome semelhante.

É ainda sugerido que o utilizador pondere se faz ou não mais sentido adicionar os seus documentos a uma das publicações existentes (Figura 126). Por questões de gestão de tempo útil e porque esta não era uma funciona-lidade crucial, não foi implementado um método automático para o efeito. Para já, isto pode ser feito enviando um email diretamente para o jacc.

130


Figura 123 - Menu lateral “so-bre” aberto

Figura 124 - Janela pop-up de sugestões automáticas (imple--mentada de raiz), mostrando 6 sugestões

Figura 125 - Janela pop-up de sugestões automáticas (implemen-tada de raiz), mostrando que não encontrou resultados semelhantes

Figura 126 - Janela pop-up nativa alertando para a possibilidade de publicações semelhantes

131

06. Projeto

Fechar janela de visualização e menus laterais

Ao abrir os menus laterais, estes podem ser identificados pelo respetivo título. Assim, foi possível criar uma forma de os fechar, idêntica à forma de os abrir – clicando na respetiva etiqueta. Para tornar este método mais intuitivo, ao abrir um menu, a sua etiqueta passa a dizer “fechar” e desloca-se para o canto superior esquerdo. Isto coloca-a numa posição paradigmática, associada a botões de fechar ou de retornar à página anterior.

Mantendo o mesmo método, ao abrir a janela de visualização, é-lhe adicionada uma etiqueta “fechar” no canto superior esquerdo (Figura 127).

Aguardar processamento

Para dar o devido feedback ao utilizador, criou-se um elemento gráfico para indicar o decorrer de processos de carregamento. Este elemento ocupa toda a altura e largura do ecrã, não sendo possível interagir com a página atrás. Isto evita o abuso do sistema.

Segundo as regras gráficas e dando a perceber que não se mudou de página, o seu fundo deste elemento é pintado de branco com alguma trans-parência. No centro, colocou-se um quadrado a girar. Isto tira partido de um forte motivo gráfico da marca (o quadrado) e alude aos ícones de carregamento standardizados (girando). Desta forma, o elemento criado é facilmente reco--nhecido como um aviso para esperar. Não tomando isto como garantido, o sinal foi reforçado com o texto “Aguarde” (Figura 128).

LocalStorage

Para que os utilizadores não tenham de redefinir as suas preferências de visualização de cada vez que entram no website, decidiu-se guardá-las no ar-mazenamento local do browser (localStorage). Mais especificamente, guardam-se as definições do mapa – vista de satélite e agrupamento de marcadores – e a for-ma de ordenação das publicações no menu “lista”. Ponderou-se ainda guardar os tipos de arquivo selecionados, mas decidiu-se esperar feedback mais concreto por parte dos utilizadores. Utilizando este método, as definições selecionadas manter-se-ão intactas apenas no browser específico onde foram selecionadas.

132


Existiam outras formas de o fazer, por exemplo, utilizando cookies ou guardando a informação na base de dados do arquivo. Optou-se por não utilizar cookies pois este é um método mais pesado e que necessita de aprova-ção dos utilizadores. Já utilizar a base de dados poderia ter interesse, pois as definições poderiam manter-se em qualquer browser onde o utilizador fizesse login. Contudo, isto não seria necessariamente vantajoso. Por exemplo, devido a questões de poder computacional e gasto de dados móveis, pode querer-se ter vista de satélite em desktop mas não em mobile.

Ponderou-se ainda utilizar a base de dados como método complementar. Se o utilizador não tivesse feito login, eram utilizadas as definições guardadas no armazenamento local, caso tivesse feito login, eram utilizadas as definições guardadas na base de dados, mas que estariam diretamente associadas a um dispositivo e browser específico. Igualmente, isto poderia ser feito guardando as definições no armazenamento local, discriminadas por utilizador. Contudo, não se achou que a implementação desta funcionalidade fosse suficientemente pertinente para já.

Figura 127 - Menú lateral “perfil” aberto; A etiqueta passa a mostrar “fechar” e subiu para o topo do menu

Figura 128 - janela pop-up usada para que o utilizador aguarde o completar de processos (desenvol-vida de raiz)

133

06. Projeto

Ajuda para utilização da interface

Como já foi dado a entender, ao longo da interface, vários elementos acionam etiquetas explicativas nativas dos browsers. Para as ver, basta colocar e manter o rato sobre esses elementos. Por exemplo, ao colocar o rato sobre o delimitador direito (final de período) da timeline, é mostrada uma etiqueta “Ver documentos produzidos até esta data” (Figura 79).

Além destas etiquetas, sempre que necessário, são mostradas mensa-gens popup para alertar ou pedir confirmação respetivamente a ações que o utilizador desempenhou. Por exemplo, para alertar que uma publicação foi submetida com sucesso, para confirmar o eliminar de uma publicação, etc. (Figura 110 e 96).

Ponderou-se ainda a criação de um pequeno tutorial de ajuda. Este seria mostrado da primeira vez que um utilizador entrasse no website (verificação feita através de uma variável guardada no armazenamento local).

Voltar a ver o tutorial seria possível através de um botão no menu “sobre”. Contudo, tomou-se a decisão de esperar o feedback futuro dos utili-zadores, para verificar se esta funcionalidade era ou não necessária.

Figura 129 - Legenda de um documento áudio produzido por Luís antero: (1) a partir da resolu-ção 8x5 (2) até à resolução 8x5

(1) (2)

134


5. Responsividade do design da interfaceComo referido, é possível carregar e redigir documentos diretamente na pla-taforma. Em dispositivos mobile, inclusivamente, é possível carregar ficheiros diretamente da câmara e/ou microfone (imagens, vídeos ou sons). Deste modo, pretendia-se que a plataforma pudesse ser usada como uma ferramenta de campo. Para que isto fosse possível, era importante que o website fosse fun-cional em dispositivos móveis. Isso foi conseguido implementando técnicas de design responsivo.

A primeira metodologia a adotar foi o uso de percentagens para de-finir a posição e tamanho dos elementos na página. Depois, foi necessário reposicionar, redimensionar e/ou redesenhar alguns elementos recorrendo a media queries.

Neste processo tentou-se ao máximo manter os elementos na sua posição relativa original. Isto é importante para que os utilizadores não necessitem de reaprender a interagir com a plataforma. Quando não foi possível fazê-lo ou foi necessário redesenhar elementos, procurou-se que o seu novo estado cor-respondesse a um standard atual de design de interface (suportando a filosofia de não se necessitar de reaprendizagem).

Resoluções empregues

Para além da visualização normal, existem quatro formas de visualização da interface para quatro resoluções de ecrã/janela diferentes – até 400 pixels de altura, até 5x9, até 1x1 e até 8x5. As janelas herdam os estilos e alterações das janelas com largura superior. Por exemplo, a janela com largura menor herda todos os estilos da janela original, com todas as alterações feitas nas janelas com larguras intermédias.

135

06. Projeto

Janelas/ecrãs até 8x5

A primeira alteração relativamente à visualização original, faz-se no-tar quando a largura da janela é no máximo 1.6 vezes maior que a altura da mesma – um rácio de 8:5. A partir desse momento as descrições dos documentos passam a uma verão mais sumária das mesmas. Por exemplo, em vez de um documento ser descrito por “Produzido por Luís Antero (5/10/2013)”, passa a ser descrito por “Luís Antero (5/10/2013)” (Figura 129). Janelas/ecrãs até 1x1

A alteração seguinte faz-se notar quando a largura da janela é menor ou igual à altura da mesma (1x1). A partir daí o logótipo/menu é substituído por uma versão simplificada:

Passa a ser usado um ícone alusivo ao standard atual para “menu”. Contudo, ao invés das três linhas horizontais normalmente utilizadas, usaram- -se quatro linhas horizontais envoltas num quadrilátero. Assim foi possível con-tinuar a remeter para os quatro tipos de arquivo anteriormente presentes no logótipo/menu. O nome do arquivo passou a ser escrito à direita do ícone e a enumeração dos tipos de arquivo voltou a ser simplificada para a palavra “digital”.

Apesar do ícone usado traduzir naturalmente que é clicável, ao colocar o rato sobre um dos dois elementos descritos (ícone ou texto), o contorno do quadrilátero passa a vermelho, reforçando a mesma ideia. Ao clicar num dos elementos, é mostrado o logótipo/menu original no seu estado “aberto”. Desta forma, é possível passar imediatamente à seleção dos tipos de arquivo.

Também a timeline é substituída por uma simplificação. Esta passa a resumir-se a dois campos para inserção da data – início e fim do período de tempo a pesquisar. Estes campos são dispostos horizontalmente para que sejam capazes de responder à mínima largura de ecrã possível. Os mesmos têm ainda a particularidade de serem mais bem otimizados para ecrãs táteis pois, sendo campos html5 nativos, cada browser é capaz de escolher a melhor forma para digitação de datas (Figura 130).

136


Figura 130 - Aspeto visual da janela principal com resolução até 1x1: (1) logótipo/menu e timeline minificados (2) logótipo aberto

(1)

(1)

137

06. Projeto

Outro aspeto alterado é o tamanho da janela de visualização e dos menus laterais. Devido ao estreitamento da largura da do ecrã (igual ou menor que a altura), em vez de visualizadas na metade direita do ecrã, estas janelas são visualizadas em ecrã inteiro. Isto inviabiliza o uso da etiqueta para as fechar. Assim sendo, passou-se a usar um botão “X” posicionado dentro da janela. Ao colocar este botão no canto superior esquerdo das janelas, estar-se-ia a seguir um standard utilizado, por exemplo, em sistemas Macintosh. Contudo, para manter a posição dos cabeçalhos nas janelas, optou-se por colocá-lo no canto superior direito – um standard utilizado, por exemplo, em sistemas Windows.

A posição do botão “X” competia com o menu de definições do mapa. Contudo, ao abrir as janelas em ecrã inteiro não é possível interagir como mapa. Desta forma, o menu de definições não precisa de ser mostrado.

Abrir as janelas em ecrã inteiro também faz com que não seja possível, por exemplo, ver e interagir com coleções ou selecionar uma localização no mapa. Para solucionar o problema, quando o utilizador seleciona opções que necessitem da interação com o mapa, a janela aberta passa a ocupar apenas a metade superior do ecrã. O mapa é mostrado na metade inferior. Sendo que nesta situação o mapa é mostrado, fazia sentido voltar a mostrar o menu de definições do mapa. Este foi colocado no canto superior direito da metade inferior do ecrã – a mesma posição que estava originalmente, relativamente ao mapa. Ao tocar na janela (fora do mapa), esta volta a ocupar a totalidade do ecrã e o menu de definições volta a ser escondido.

As figuras 131 e 132 ilustram as alterações na janela de visualização e menus laterais respetivamente.

138


Figura 132 - Aspeto visual de uma menu lateral (“procurar”) com resolução até 1x1: (1) Estado normal (2) Modo de seleção de uma localização no mapa

Figura 131 - Aspeto visual da janela de visualização com resolução até 1x1: (1) Estado normal (2) Modo de visualização da coleção

(1)

(1)

(2)

(2)

139

06. Projeto

Janelas/ecrãs até 5x9

A partir da resolução 5x9 dá-se um grande estreitamento da largura janela. Por esta razão, foi criada uma versão do logótipo/menu ainda mais simplifi-cada. Nesta versão o texto à direita do ícone passa a mostrar apenas as iniciais do nome do arquivo – adchc. Esta forma de visualização era importante, principalmente, para iPhone X (Figura 133).

Janelas/ecrãs com máximo de 400 pixels de altura

Era ainda necessário criar uma versão para janelas muito estreitas em altura. Esta é, principalmente, utilizada em dispositivos mobile em orientação horizontal (landscape) e em modo escrita (com o teclado aberto).

O tamanho dos elementos na janela é calculado em relação à altura da mesma. Assim sendo, o modo de escrita resultava em elementos demasiado pequenos (o website era mostrado na totalidade em cerca de metade da altu-ra do ecrã do dispositivo, sendo a outra metade dedicada ao teclado digital nativo). Assim sendo, foi necessário redimensionar todos os elementos para o dobro do tamanho.

Além disso, nesta vista reduziram-se os recursos ao essencial. Primeiro, o logótipo/menu e a timeline são mostrados como na resolução 5x9. Depois, sendo que a principal função da versão mobile do website é a publicação em tempo real (website como ferramenta de campo), todos os menus laterais são escondidos à excepção dos menus “publicar” e “perfil” (como para publicar é necessário fazer login, não faria sentido mostrar apenas o menu “publicar”) (Figura 134).

Implementações não utilizadas

Antes da timeline ser diretamente convertida para dois campos data, esta era simplificada mostrando um máximo de 3 anos até à resolução 1x1.5, e um máximo de 4 anos até à resolução 1x1.

140


Figura 133 - Aspeto visual da janela principal com resolução até 5x9 (logótipo/menu em simplificação máxima)

Figura 134 - Aspeto visual da janela principal com resolução até 400 pixels de altura (logótipo/menu em simplificação máxima; apenas os menus laterais “perfil” e “publicar”; campos da timeline dispostos horizontalmente)

141

06. Projeto

Particularidades dos browsers

Desenhar e programar um website a partir de um ficheiro em branco é largamente mais complexo que fazê-lo com recurso a um Cms (Content Mana-gement System), como Wordpress, Drupal, etc. Um dos momentos em que essa complexidade é sentida, é ao garantir que o website é funcional na maioria ou totalidade dos browsers.

Diferentes browsers têm algumas diferenças que devem ser tomadas em atenção no momento de programar um website – certos browsers não suportam algumas funções ou sintaxes. Desse modo, foi necessário procurar perceber quais as diferenças e como contorná-las. Parte deste trabalho foi feito lendo a documentação dos recursos utilizados. Outra parte foi feito testando o website em vários browsers e fazendo as devidas retificações.

Uma particularidade encontrada no Safari e Edge foi o facto de não ser possível definir a opacidade da cor dos contornos svg através da função rgba (vermelho, verde, azul, opacidade) no campo stroke (cor do contorno). Para implementar opacidade foi necessário declará-la separadamente através do campo stroke-opacity. No caso do Edge, o mesmo acontecia para a opacidade da cor do corpo (campo fill), pelo que também esta foi definida separadamente, através do campo opacity.

Figura 135 - visualização do website em Chrome mobile: (1) a barra de ferramentas superior é mostrada por predefinição (2) barra de ferramentas superior escondida depois de fazer scroll (3) Calendário para escolha de data, ativado ao clicar nos campos da “timeline” (1) (2) (3)

142


Figura 136 - visualização do website em Safari mobile: (1) as barras de ferramentas de cima e baixo são mostradas por predefinição (2) Calendário para escolha de data na parte inferior da janela, ativado ao clicar nos campos da “timeline”

Devido às suas demasiadas limitações e à descontinuação do mesmo, não se desenvolveu suporte para Internet Explorer. Ao abrir o website com este browser, é mostrada uma mensagem sugerindo o uso do Chrome ou um outro browser mais moderno.

Os browsers mobile têm também algumas particularidades em relação às versões desktop. Uma delas é a presença das barras de ferramentas nativas que ocupam parte do ecrã. Isto obriga o utilizador a fazer scroll para ver a página na totalidade (Figura 135). No caso particular do Safari mobile foi necessário procurar formas de desativar o arrastamento da janela, implementado por defeito. Além disso, foi ainda necessário alterar a posição de alguns elementos e abdicar do menu “apps” (Figura 136).

Por vezes os browsers são capazes de interpretar um toque no ecrã como sendo um clique de rato, mas nem sempre isso acontece. Deste modo, foi ainda necessário fazer as devidas implementações para que o toque fosse assim interpretado (implementar event listeners dedicados a ecrãs táteis).

Além das descritas anteriormente, outras particularidades foram en-contradas e resolvidas. Outras foram mais tardiamente detetadas, não tendo ainda sido resolvidas. Nenhuma delas representa nenhum tipo de problema crítico, pelo que se optou por resolver-las futuramente.

(1) (2)

143

06. Projeto

Webapp

Para tornar a sua utilização mais cómoda, foi implementada uma forma de instalar uma webapp, recorrendo ao menu definições do browser e adicio-nando o website ao menu principal do dispositivo. Desta forma, o website fica acessível através de um ícone de aplicação e abre sempre em ecrã inteiro. Isto resolve o problema da intrusão da barras de ferramentas do browser (Figura 137).

URLs para publicações ou pesquisas específicas

Sendo que apenas existe uma página onde todas as funções são reali-zadas, não existem endereços específicos para as determinadas publicações, menus, etc. Contudo, ponderou-se a criação de um sistema para que estas pudessem ser partilhadas individualmente através de links. Os links funcio-nariam passando os devidos argumentos de procura (como na api) assim como o id da janela aberta (janela de visualização ou um dos menus laterais). Por exemplo “https://arquivochc.dei.uc.pt?postid=114#view”. Assim, era possível que ao aceder ao link o utilizador visse um estado específico da interface ao invés do estado inicial do website.

URLs para publicações ou pesquisas específicas

Sendo que apenas existe uma página onde todas as funções são reali-zadas, não existem endereços específicos para as determinadas publicações, menus, etc. Contudo, ponderou-se a criação de um sistema para que estas pudessem ser partilhadas individualmente através de links. Os links funcio-nariam passando os devidos argumentos de procura (como na api) assim como o id da janela aberta (janela de visualização ou um dos menus laterais). Por exemplo “https://arquivochc.dei.uc.pt?postid=114#view”. Assim, era pos-sível que ao aceder ao link o utilizador visse um estado específico da interface ao invés do estado inicial do website.

Figura 137 - Webapp do adchc: (1) Ícone no menu principal do dispositivo (2) Janela principal da Webapp (ecrã inteiro)

(1)

(2)

144


6. Programação do lado servidorDomínio, alojamento e configurações

Conseguir um domínio e alojamento para o website é uma responsabilidade a encargo do jacc, que pode ser tratada após a finalização do projeto. Con-tudo, para que se pudessem fazer os devidos testes, era necessário conseguir uma solução provisória. Por questões de segurança, o domínio deveria ser https. O alojamento deveria incluir a base de dados, para que fosse possível alojar informação sobre publicações, utilizadores, etc. Tudo isto foi foi pe-dido e facultado pelo helpdesk do Departamento de Engenharia Informática da Universidade de Coimbra.

Existia uma versão http do domínio (não segura). Por questões de segurança, pediu-se à mesma entidade para criar um script (htaccess) que, ao abrir esta versão, redirecionasse o utilizador para a respetiva versão https (segura).

Por fim, para reduzir o volume de dados enviados para o browser e agilizar o carregamento do website, pediu-se que os ficheiros alojados fos-sem comprimidos através de gzip. O website foi provisoriamente alojado em https://arquivochc.dei.uc.pt.

145

06. Projeto

Base de dados

Para guardar todas as informações relativas a publicações, documentos e utilizadores foi criada uma base de dados relacional mysql. Aí foram acau-teladas as devidas relações de integridade e unicidade dos dados.

Foram ainda criados alguns tipos de utilizador com diferentes permis-sões de acesso à base de dados. Por exemplo, um utilizador que pode ver e editar todas as informações na base de dados à exceção daquelas que constem na tabela de palavras-passe. A criação deste utilizador de acesso era especialmente importante devido ao facto de ainda não existir uma interface backoffice pronta a utilizar pelo jacc. Assim, é possível que façam edições diretamente na base de dados sem correr o perigo de corromper dados como palavras-passe, salts, etc (um utilizador comum não tem qualquer tipo de acesso direto ao gestor de base de dados; apenas pode executar ações através da interface ou api do adchc). Como já referido, como trabalho futuro, prevê-se a criação de uma interface backoffice para a gestão/edição de todos os aspetos necessários, para utilização do jacc.

Além dos utilizadores de acesso à base de dados, foram criados 4 tipos de conta de utilizador do website – Programador, jacc, Equipa oficial do jacc e utilizador comum. Como já referido, esta distinção serve para diferenciar ações permitidas na interface, assim como organizar a listagem de publicações por aprovar na futura interface backoffice.

Ferramentas de programação do lado servidor

A programação do lado servidor foi também conseguida, totalmente, a partir de ficheiros em branco. Foi utilizado php e/ou mysql para ler e escrever na base de dados, processar dados, certificar a segurança dos dados passados por utilizadores através do browser, retornar dados em formato json e retornar mensagens de feedback.

146


Funções do lado servidor

Segurança e integridade no tratamento de dados:

Todos os processos do servidor que recebem dados passados por uti-lizadores (no browser) têm em comum um script que certifica a sua credibili-dade – converte os devidos caracteres em caracteres html, verifica o tipo de variável, etc.

Como referido anteriormente, todos os formulários com informação crítica são enviados através do método POST, garantindo que os dados viajam encriptados na rede e não são visíveis no url.

Além de encriptar palavras-passe no lado cliente, no lado servidor, estas são adicionadas a um número aleatório (encriptação com salt) e novamente encriptadas através do algoritmo sha512.

Para assegurar a integridade do sistema, todos os processos são testados antes de realmente executados. Se se verificar que todos eles podem ser com-pletados com sucesso (sem erros), são executados. Caso contrário, nenhum o é. Isto foi conseguido recorrendo a blocos try e transações SQL.

Retornar informações básicas das publicações:

Uma das funções do lado servidor é retornar informações relativas à pré-visualização de publicações. Estas são pedidas à base de dados, convertidas para formato json e enviadas para o browser.

Esta função é a base de funcionamento do menu “procurar”, podendo receber quaisquer campos do mesmo como argumento de filtra-gem. Caso não lhe seja passado nenhum argumento, são retornadas todas as publicações de todos os tipos de arquivo – método usado para iniciar o website. Isto pode significar uma grande quantidade de dados para processar e enviar. Desta forma, apenas são pedidas e retornadas informações essenciais para a pré-visualização das publicações.

147

06. Projeto

Retornar informações dos documentos:

Retornar informações acerca dos documentos de uma publicação é outra das funções do servidor. Assim como na função descrita anteriormente, estas são pedidas à base de dados, convertidas para formato json e enviadas para o browser.

Esta função recebe como argumento o número identificador de uma publicação (id) e retorna informações detalhadas sobre todos os documentos da mesma. Estas informações incluem o url para acesso ao documento no servidor. Deste modo, é possível aceder e reproduzir o mesmo.

Carregar publicações (upload):

Era ainda necessário criar um função para carregamento de publica-ções (ficheiros e informação associada).

Esta função recebe como argumentos os campos preenchidos e os ficheiros carregados no menu “publicar”.

Depois de fazer verificações de segurança aos mesmos, carrega-os para a base de dados e uma pasta no servidor, respetivamente. Esta é uma pasta dedicada a ficheiros por aprovar, onde os mesmos ficam a aguardar aprovação. Também na base de dados, a publicação é marcada como “por aprovar”. Isto permite distinguir as publicações aprovadas das não aprovadas, podendo mos-trar estas últimas apenas ao jacc (administradores) e ao respetivo publicador.

Aprovar, eliminar ou editar publicações – administradores:

Quando uma publicação é carregada com sucesso, é enviado um e-mail aos administradores – jacc – alertando que uma publicação está a aguardar aprovação. Nesta mensagem consta ainda um link para o website do arquivo.

Como já foi referido, em cada publicação não aprovada existem botões para aprovar, eliminar ou editar (em phpma.dei.uc.pt), apenas visíveis para os administradores (estes tem que ter feito login previamente, para poder poder ver os botões).

148


Ao aprovar ou eliminar uma publicação, apenas é passado ao servidor o respetivo número identificador. Para garantir que estas funções são apenas usadas pelos administradores, é sempre verificado qual o utilizador com sessão iniciada. Ou seja, mesmo que um utilizador comum tente usar uma destas funções, o acesso é-lhe negado.

Aprovar uma publicação move os respetivos documentos da pasta de documentos por aprovar, para a pasta de documentos aprovados. Além disso, altera o estado da publicação na base de dados para “aprovado”. Desta forma, a mesma passa a ser visível para qualquer utilizador que visite o website.

Eliminar uma publicação elimina definitivamente a publicação na base de dados, assim como os respetivos documentos no servidor.

Escolher editar uma publicação abre uma interface para gestão de base de dados (phpma.dei.uc.pt) numa nova janela. Aqui, os administradores podem iniciar sessão e editar qualquer informação relativa a publicações ou utilizadores. Não podem, porém, ver ou editar informações relativas a palavras-passe.

Eliminar ou editar – utilizadores:

Os utilizadores comuns têm também uma forma de eliminar as suas publicações. A função responsável por fazê-lo é idêntica à função usada pelos administradores para eliminar publicações. Contudo, em vez de verificar que o utilizador é administrador, verifica que o utilizador com sessão iniciada é o criador da publicação.

A função para edição de publicações por parte dos utilizadores foi começada mas não finalizada até à data. Assim, é sugerido aos utilizadores que, se pretendem editar uma publicação, enviem um e-mail aos responsáveis pela plataforma. Eles farão as edições pedidas pessoalmente.

Quando finalizada esta função, os utilizadores serão capazes de editar as suas publicações diretamente na plataforma. As edições serão mantidas em lista de espera até que lhes seja concebida aprovação.

Pretende-se ainda que um utilizador possa acrescentar conteúdos a uma publicação, mesmo que não a tenha criado (publicações colaborativas).

149

06. Projeto

Converter e comprimir ficheiros:

Para agilizar a velocidade de carregamento dos documentos, ponderou--se implementar a conversão e compressão dos ficheiros carregados através de bibliotecas como FFmpeg. Seriam criados ficheiros com vários tipos de com-pressão e tamanhos. Desta forma, dependendo do tamanho do dispositivo, da sua capacidade de processamento e da qualidade da ligação à internet, poderia ser carregada uma versão do documento com maior ou menor qualidade. Por exemplo, como os telemóveis têm ecrãs menores, não é necessário carregar imagens tão grandes como em tablets; carregando imagens menores poupa-se largura de banda e agiliza-se o carregamento.

Contudo, apesar de vantajosa, esta funcionalidade não era crucial. Então, devido a questões de gestão temporal (esta era uma tarefa demorada), decidiu-se deixar o seu desenvolvimento para trabalho futuro.

Criar conta:

Ao criar uma conta, o respetivo formulário é também enviado e gerido no servidor. Assim como nas funções anteriores, os dados são recebidos e são feitas as devidas verificações de segurança. Os dados são depois guardados na base de dados, juntamente com um código para confirmação do perfil. Este último é formado através da encriptação de um número aleatório, email e nome de utilizador concatenados.

150


Confirmar Conta:

Uma vez criado o perfil, é enviado um e-mail ao utilizador (para o endereço com que se registou) com uma hiperligação para confirmação do endereço de e-mail. A mesma contém o código de confirmação, email e nome de utilizador.

Ao clicar na hiperligação, o utilizador é identificado via endereço de e-mail e nome de utilizador. Depois é comparando o código de confirmação da hiperligação com o código de confirmação da base de dados. Caso estes sejam iguais, o perfil é validado. Feito isto, o código de confirmação é redefinido alea-toriamente, inutilizando o código anterior. Isto é importante porque este campo (código de confirmação) é igualmente usado para redefinição da palavra-passe.

Só depois de validar o seu perfil clicando na hiperligação, o utilizador é capaz de fazer login. Isto é importante para assegurar que o endereço de e-mail registado é real e pertence ao utilizador.

151

06. Projeto

Login:

A função de login recebe como argumentos e-mail ou nome de utili-zador, e palavra-passe. Depois, encripta esta última com o mesmo número aleatório (salt) com que a conta foi criada e compara os dados passados com os dados na base de dados. Se estiverem corretos, é aberta uma sessão php onde são guardadas as informações pessoais do utilizador (nome, data de nascimento, etc.). Estas são ainda passadas ao browser em formato json.

Foi implementado um método para enviar um email de aviso de início de sessão de cada vez que um utilizador fizesse login. Contudo, este atrasava o processamento em cerca de um ou dois segundos. Assim sendo, resolveu-se não o utilizar para já.

Como afazeres adicionais, ponderou-se guardar a sessão do utilizador na base de dados, associada ao browser, nome do dispositivo e IP. Ponderou-se ainda implementar um método contra brute force attack (ataque de força bruta) e estudaram-se outras formas de fazer um login seguro. Contudo, por questões de gestão temporal, decidiu-se não implementar nenhum destes extras para já. Esta decisão deveu-se ainda ao facto de se pretender migrar o sistema de login para oAuth – um protocolo para autenticação standardizado. Este protocolo implementa todos os métodos descritos anteriormente e muitas mais formas e de garantir um login seguro e cómodo (por exemplo, iniciar sessão com a conta de Facebook ou Google).

Logout:

A função de logout apaga as variáveis guardadas na sessão, destrói a sessão e apaga a informação do utilizador guardada no browser.

Redefinir palavra-passe:

A função para redefinição de palavra-passe permite redefinir a palavra--passe de uma conta sem ter que se fazer login. Esta recebe como argumento, o endereço de e-mail associado à respetiva conta. Depois, envia um e-mail para o mesmo, com uma hiperligação para uma página onde a palavra-passe pode ser redefinida. Isto garante que apenas o dono da conta (dono do e-mail) pode alterar a sua palavra-passe.

152


A hiperligação é formada pelo endereço de email, nome de utilizador e um código de confirmação momentaneamente gerado (é gerado da mesma forma, mas um código diferente do código de confirmação para verificação de conta). Antes de enviar o e-mail ao utilizador, este código é guardado na base de dados. Assim, garante-se que só a hiperligação com o código correto permite alterar a palavra-passe da respetiva conta.

Uma vez enviada a nova palavra-passe, o código de verificação é redefinido para um novo número aleatório, inutilizando a hiperligação anterior (só pode ser usada uma vez), e a palavra passe é redefinida na base se dados com a devida encriptação. Feito isto, o utilizador é direcionado para a página do arquivo.

Eliminar conta:

A função para eliminar conta recebe como argumento a palavra-passe da conta com sessão iniciada. Recebe ainda uma opção que define se o utili-zador apenas pretende apagar os seus dados e manter as publicações (como pertencentes a um utilizador anónimo) ou se pretende eliminar a sua conta e publicações definitivamente.

A primeira opção, apenas define os dados do utilizador em branco da base de dados, continuando a permitir que o utilizador faça login e redefina os mesmos. A segunda opção apaga definitivamente a sua conta e respetivas publicações. Esta é uma ação sem retorno.

Qualquer que seja a opção escolhida, a função encerra a sessão do utilizador e direciona-o para a página do arquivo.

153

06. Projeto

Desenvolvimento da api

A api desenvolvida implementa duas das funções descritas anteriormente – retorno de informações básicas das publicações e retorno de informa-ções dos documentos. Como tal, implementa também os respetivos métodos de segurança e integridade no tratamento de dados. As funções recebem os mesmos argumentos referidos anteriormente.

Garantia de compatibilidade:

Para garantir que as aplicações desenvolvidas com a api continuam funcionais mesmo depois de feitas atualizações ao mesmo, a api é discrimina-da por versões. Estas basem em https://arquivochc.dei.uc.pt/api/v, seguido do número da versão. Por exemplo, para esta primeira versão: https://arquivochc.dei.uc.pt/api/v1.

Para perceber como cada versão funciona deve ser lida a respetiva documentação. Esta pode ser lida acedendo ao link da versão seguido de “/doc.txt”. Por exemplo: https://arquivochc.dei.uc.pt/api/v1/doc.txt.

Autenticação:

Sendo que as funções facultadas não retornam dados críticos, para fa-cilitar o uso da api decidiu-se não obrigar à autenticação. Contudo, aquando da migração do sistema de login para oAuth, pretende-se criar uma nova versão da api cujo autenticação siga também o mesmo protocolo. Isto permitirá, por exemplo, limitar os pedidos ao servidor (para não o sobrecarregar) e ter esta-tísticas de uso. Poder-se-á ainda facultar funções mais avançadas que exigem autenticação, como carregamento de publicações.

Pedidos e respostas:

Os pedidos à api são feitos através do método GET do protocolo http. Em JavaScript isto pode ser feito usando a função nativa XMLHttpRequest (ajax). Os resultados são devolvidos em formato json – um formato standardi-zado para guardar e trocar informação entre sistemas de forma simples e rápida.

154


7. DivulgaçãoA parte mais importante deste projeto era desenhar e programar o website do arquivo. Contudo, para que este servisse o seu propósito era neces- sário comunicá-lo ao público alvo. Para isso, criaram-se vários artefactos de comunicação.

Cartazes

Ao longo dos capítulos anteriores, foram já reveladas algumas maquetes para a comunicação do arquivo via cartaz. Na Figura 137 pode ver-se o cartaz final, a colocar nas ruas de Coimbra. Este cartaz serve igualmente de flyer. O processo de criação completo pode ser consultado no Anexo 3.

Figura 138 - Cartaz promocional

155

06. Projeto

Redes Sociais

Tirando partido do enorme potencial divulgador do Facebook e Insta-gram, foram também criados perfis e respetivos materiais gráficos para divul-gação online (Figura 138).

Instalações

Além dos meios já descritos foram também pensadas e implementadas instalações para comunicação dos conteúdos do arquivo, no âmbito do projeto Dar a Ouvir. Paisagens sonoras da Cidade. Assim como a ms01 (João Bicker, Pedro Martins, Penousal Machado e Tiago Martins), referida no Capítulo 3, estas são formas físicas de aceder a alguns dos conteúdos do arquivo, demons-trando o potencial do mesmo para a criação artística.

Uma das instalações foi chamada de “Murmur” e esteve aberta ao público de 1 de Julho a 2 e Setembro do presente ano (2018) no Convento de São Francisco (Coimbra). Esta retratava a paisagem visual e sonora do Jardim da Sereia (Alta de Coimbra), que apenas podia ser visualmente completada através da interação das pessoas – as três fotografias em grande formato, dispostas panoramicamente nas paredes (base impressa sob complemento projetado), eram coloridas ou deixavam de estar distorcidas através dos sons que os visitantes faziam (amplitude de cada frequência), somados ao som de fontes do jardim, sempre presente na sala.

Figura 139 - Página de Facebook (facebook.com/arquivodigitalchc)

156


Figura 140 - Trabalhos de prepa- ração da instalação Murmur, no Convento de São Francisco

Sobre a imagem colocada em frente à porta da sala, existia um poema visual da inscrição em Latim presente no arco de entrada do jardim. Este poema evidenciava as três palavras chave da instalação: contegat (escondido) – representado no poema escondendo a metade de baixo da palavra; font (fonte) – representado no poema através da repetição vertical, aludindo a uma queda de água; e murmur (murmúrio) – representado no poema incrementando pro-gressivamente o tamanho dos caracteres, convidando os murmúrios a crescer.

Contegat serve de analogia ao ambiente misterioso do jardim (um jardim pouco ornamentado; quase uma floresta), que foi retratado na instalação pelo facto das imagens não estarem completas (com partes escondidas) até que os visitantes interagissem com a instalação. Font era presente no som constante da água das fontes do jardim. Murmur era o elemento que os visitantes deveriam trazer, ao reproduzir sons.

Como já pode ter sido dado a entender, pelo facto da paisagem não estar completa sem os visitantes, a instalação tinham uma mensagem subli-minar – era preciso trazer visitantes ao jardim e trabalhar na ornamentação daquele espaço. Para enfatizar a mensagem, a imagem sobre o poema foi deliberadamente projetada com uma inclinação considerável (torta), como forma de crítica ao que ainda há por “endireitar” no Jardim da Sereia (Figuras 139, 140 e 141).

157

06. Projeto

Figura 142 - (1 a 6) Instalação Murmur, Convento de São Francisco

(1) (2)

(3)

(4)

(5) (6)

158

Arquivo Digital do Centro Histórico de Coimbra 07. Testes

pArA poder AveriguAr A quAlidAde da performance e interface do arquivo, o mesmo foi submetido a testes de avaliação automática, assim como testes de utilizador presenciais. Através dos mesmos, foi possível detetar alguns proble-mas de otimização, uns já resolvidos, outros deixados para trabalho futuro.

1. Avaliação automáticaA avaliação automática foi realizada através de uma ferramenta da Google para auditoria web – a Lighthouse. Avaliou-se o website quanto a performance, acessibilidade, melhores práticas e otimização para motores de busca (SEO). A Figura 143 mostra os resultados da última auditoria, na qual se verifica que o website do adchc obteve muito bons resultados em todas as áreas.

Apesar de um bom resultado, das quatro, a área menos otimizada foi a performance. Contudo, como é sugerido na Figura 144, esta pode ser melhorada através do uso de compressão gzip – cujo implementação já foi requerida aos responsáveis pelo web host do site – e ao alargar os períodos em que os ficheiros js e css são guardados em cache pelos browsers dos utilizadores. Esta última retificação não foi ainda implementada, devido ao facto dos ficheiros ainda se encontrarem em fase de alterações.

Além de testar o website do adchc, testaram-se também os websites do Facebook (Figura 145), YouTube (Figura 146) e Google Maps (Figura 147) com a mesma ferramenta. Em comparação, pode verificar-se que o adchc é um website mais otimizado do que estes três sites largamente utilizados em todo o mundo, apenas ficando três pontos percentuais em cem abaixo do YouTube e Google Maps quanto a acessibilidade, e sete pontos percentuais em cem abaixo do Google Maps quanto a melhores práticas. Quando a performance, o adchc fica trinta e quatro pontos (no mínimo) acima dos restantes, quarenta e dois pontos acima do Facebook quanto a acessibilidade, doze pontos acima do mesmo quando a melhores práticas, trinta pontos acima do Youtube quanto a otimização para motores de busca, e quarenta pontos acima do Facebook no mesmo aspeto.

Testes

159

Figura 143 - Resultado da mais recente auditoria Lighthouse ao website do adchc (27 de Agosto de 2018)

Figura 144 - Sugestões para otimi-zação, resultantes da mais recente auditoria Lighthouse ao website do adchc (27 de Agosto de 2018)

07. Testes

160


Figura 145 - Resultado da auditoria Lighthouse a www.facebook.com (27 de Agosto de 2018)

Figura 146 - Resultado da auditoria Lighthouse a www.youtube.com (27 de Agosto de 2018)

Figura 147 - Resultado da auditoria Lighthouse a www.maps.google.com (27 de Agosto de 2018)

2. Testes de utilizadorForam realizados treze testes de usabilidade a doze utilizadores (um deles testou ambos desktop e mobile) com idades compreendidas entre os vinte e os cinquenta e três anos – média de, aproximadamente, trinta e dois anos e um desvio padrão de, aproximadamente, treze anos – e com grau de habilitações web compreendido entre 1 e 3, numa escala de 0 a 3 – um grau médio de 2,4 e um desvio padrão de, aproximadamente, 0,84.

Aos utilizadores foram apresentadas sete tarefas que os mesmos deveriam desempenhar na plataforma: ver apenas publicações de 2013 a 2015; ver uma fotografia da Universidade; criar um perfil de utilizador; fazer login; fazer uma publicação (um texto e uma imagem); procurar publicações feitas por Daniel; eliminar a publicação feita anteriormente.

07. Testes

161

Para cada uma destas tarefas foi anotado o tempo despendido e aprecia-ções do que correu mal ou bem. Foi ainda registado o nome, idade, habilita-ções web numa escala de 0 a 3, se já conhecia ou não a plataforma, o sistema operativo utilizado e o browser utilizado. Todas estas anotações serviram depois para discriminar o resultado das tarefas (problemas encontrados ou não) em três graus de relevância – “para resolver primeiro”, “para resolver por último” e “resolvido ou sem problemas”.

Os testes de utilizador foram deveras úteis para encontrar alguns problemas da interface e listar afazeres. Por exemplo, foram já resolvidos pro-blemas como evitar a seleção de texto na timeline, colocar um asterisco em falta no formulário de criação de perfil, colocar os botões “escolher coordenadas no mapa” e “usar data e hora atuais” antes dos campos que estes preenchem, permitir underscore e números no nome de utilizador, corrigir um erro exis-tente ao repor todos os campos, resolver um problema que fazia com que o carregamento de ficheiro bloqueasse, e definir um ano mínimo para a data das publicações.

Como tarefas a desempenhar primeiro identificaram-se: reescrever o código de modo a não usar argumentos pré-definidos nas funções (os browsers antigos não suportam), iniciar o mapa com vista de satélite em desktop e/ou incluir mais informações no mapa (pontos de interesse, etc.), criar um botão “repor campos de pesquisa” na janela principal, corrigir um erro que faz com que o campo ano tenha de ser preenchido antes do mês e dia na data de pro-dução dos documentos, lançar uma mensagem pop-up, e/ou centrar o mapa na janela e redefinir o zoom quando são feitas alterações no mapa.

Identificaram-se como tarefas a desempenhar mais tarde: definir perí- odos na timeline clicando na mesma, retornar imediatamente os arquivos selecionados no logótipo/menu ao clicar nos mesmos (a considerar), tirar o asterisco do bloco de informações dos documentos depois do mesmo estar aberto, centrar as informações dos documentos na janela de carregamento quando é adicionado um novo documento, evidenciar que os campos a vermelho são obrigatórios, procurar resultados que incluam pelo menos uma das palavras pesquisadas em vez da totalidade da frase, utilizar apenas um dos termos “conta” ou “perfil”, disponibilizar um menu de ações e defini-ções ao clicar com o botão direito do rato, e colocar a etiqueta do menu de “procurar” com contorno vermelho quando existem campos de filtragem preenchidos no mesmo.

Na Figura 148 é apresentada o registo do resultado dos testes.

07. Testes

162


Figura 148 - Tabela de resultados dos testes de usabilidade

Figura 148 - Tabela de resultados dos testes de usabilidade

07. Testes

163

3. Reflexão sobre os resultados obtidos

Em retrospetiva, tanto os testes de avaliação automática como os testes a utilizadores foram cruciais na deteção e resolução de vários problemas não previstos. Uns foram já resolvidos, outros foram deixados para trabalho futuro. Contudo, os testes feitos contribuíram já para um sistema mais rápido e um interface mais fácil e intuitiva.

A avaliação automática ajudou a otimizar, principalmente, problemas de performance e usabilidade, sugerindo formas de agilizar o carregamen-to do website e de o tornar mais ajustado a utilizadores com défices visuais. Os testes com utilizadores reais ajudaram, principalmente, a identificar formas de tornar a interface mais naturalmente utilizável, através da observação e ano-tação do comportamento dos utilizadores face às tarefas que lhes foi pedido para desempenhar.

O comportamento de quase todos os utilizadores alertou para algum tipo de melhoria. No entanto, dado que as mesmas dificuldades eram mui-tas vezes verificadas de utilizador para utilizador, notou-se a importância de resolver os problemas já encontrados antes de dar continuidade aos testes com utilizadores. Por essa razão, ainda não se completou um total de trinta testes planeados à priori, tendo-se realizado apenas os treze referidos anteriormente.

No entanto, dado aos progressos conseguidos através dos testes automá-ticos e com utilizadores, não se tenciona restringir este trabalho aos 17 testes restantes, mas sim dar continuidade a ambos os tipos de teste para que outras melhorias possam continuar a ser feitas no futuro.

07. Testes

164

Arquivo Digital do Centro Histórico de Coimbra 08. Conclusão

A Arquivo digitAl do centro histórico de coimbrA (adchc) é uma plataforma online construída para dar continuidade ao trabalho de preservação das memórias do Centro Histórico de Coimbra (chc) e disponibilizá-las da forma mais cómoda possível àqueles que as quiserem consultar. O mesmo incentiva a colaboração da comunidade para o upload e download de docu-mentos, disponibilizando-os gratuita e dinamicamente, tornando-se assim numa proveitosa ferramenta para estudos sociais e criação artística.

Nesta dissertação foram apresentados os estudos e desenvolvimentos feitos quanto ao design e desenvolvimento da identidade gráfica do adchc, design e programação da plataforma online, api, aplicação desenvolvida através desta última, artefactos de divulgação, e instalações audiovisuais para divulgação e demonstração do uso do arquivo na arte. Constou ainda deste trabalho a inserção de documentos, assim como a procura e diálogo com potenciais publicadores na plataforma.

Conclusões e perspetivas futuras

165

Os trabalhos foram realizados em parceria com o Jazz ao Centro Clu-be, professores e alunos do curso de Sociologia da Faculdade de Economia da Universidade de Coimbra, e o Centro de Documentação 25 de Abril da Univer-sidade de Coimbra. Todos os artefactos produzidos estão em estado funcional e foram já (a 30 de agosto de 2018) apresentados publicamente no Convento de São Francisco (Coimbra) – a plataforma em versão beta e todos os restantes artefactos em versão final.

Independentemente disso, existem ainda tarefas a desenvolver no futuro. Umas foram previstas desde o início, outras detetadas através dos testes de usabilidade e performance. Algumas delas foram já mencionadas ao longo do Capítulo 6. Apresenta-se de seguida uma listagem completa daquelas que se ponderam concretizar:

1. No logótipo/menu: incorporar caligrafía dos utilizadores; criar es-tado intermédio de seleção para os tipo de arquivo (se o tipo de arquivo não está a ser visualizado na totalidade); criar botão para ver todas as publicações de uma coleção (caso não estejam todas visíveis devido aos tipos de arquivo selecionados); trocar o cursor pointer para o cursor pré-definido, se o rato estiver sobre o único tipo de arquivo selecionado;

2. No mapa: centrar mapa (no espaço visível da janela) na zona pro-curada (através dos menus laterais); criar um método de expansão dos marcadores perfeitamente sobrepostos; desenvolver o aspeto visual dos marcadores agrupados para que sejam igualmente in-terativos (como os marcadores normais); iniciar o mapa com vis-ta de satélite em desktop e/ou incluir mais informações no mapa (pontos de interesse, etc.); lançar uma mensagem pop-up, e/ou centrar o mapa na janela e redefinir o zoom quando são feitas al-terações no mapa.

3. Nas definições do mapa: em mobile, abrir o menu com touch (down e up) em vez de “rato sobre”.

4. Na timeline: carregar na barra para definir a posição do marcador de início de período; criar um método vertical de expansão dos marcadores para poder visualizar aqueles que possam estar sobre-postos;

5. Na janela de visualização de publicações: reprodutores de áudio e vídeo desenhados de raiz; editar publicações diretamente na pla-taforma; implementar vídeo em direto através da api do YouTube.

08. Conclusão

166


6. Nos menus laterais: carregar os conteúdos dos menus através de ajax, apenas quando o utilizador pretender abrir um dado menu; permitir ordenar documentos de forma personalizada ao fazer ou editar publicações; verificar se existem ficheiros parecidos aos que se pretendem carregar (alertar o utilizador e, posteriormente, os administradores); criar botões de pesquisa “apenas não publicado por mim” e “apenas aprovado” junto do perfil de utilizador; criação de um formulário para submissão de aplicações desenvol-vidas com a api do adchc, diretamente na plataforma; através do sistema de sugestões automáticas, mostrar o número de publicações que vão ser encontradas, antes do utilizador sub-meter o formulário de procura; tirar o asterisco do bloco de informações dos documentos depois do mesmo estar aberto; centrar as informações dos documentos na janela de carregamento quando é adicionado um novo documento; devolver resultados que incluam pelo menos uma das palavras pesquisadas em vez da totalidade da frase; utilizar apenas um dos termos “conta” ou “perfil” (escolher o melhor através de mais testes); colocar a eti-queta do menu “procurar” com contorno vermelho quando exis-tem campos de filtragem preenchidos no mesmo;

7. No servidor: comprimir e converter os ficheiros carregados (ver-sões de vários tamanhos); carregar documentos diretamente para as redes sociais; realojar o site num web host definitivo com um domínio definitivo;

8. Na otimização do código: reduzir o tamanho do nome das variá-veis; simplificar algumas funções; testar o uso de classes; minificar as respostas json, reescrever o código de modo a não usar argu-mentos pré-definidos nas funções; melhorar a compatibilidade entre browsers; corrigir um erro que faz com que o campo ano tenha de ser preenchido antes do mês e dia na data de produção dos documentos;

9. Noutros âmbitos: criar sticker de alerta para eventos no Centro Histórico (colocado no canto inferior esquerdo, por cima da time-line); tutorial e página de ajuda à navegação; limitar o tamanho de letra mínimo; criar novas formas de visualização de informação; criar um botão “repor campos de pesquisa” na janela principal; disponibilizar um menu de ações e definições ao clicar com o botão direito do rato.

08. Conclusão

167

A definição de tarefas feita inicialmente (Figura 45) foi assumidamente ambiciosa, pelo que era já expectável que nem todas elas pudessem ser realizadas em tempo útil. Por esta razão, as mesmas foram distinguidas entre requisitos e extras no relatório e apresentação intermédios desta dissertação. Contudo, criar uma planificação ambiciosa foi crucial para conseguir alcançar resultados mais elaborados e interdisciplinares. Foi ainda importante numa perspetiva pessoal, dado à quantidade de técnicas de design e programação aprendidas através do desenvolvimento do projeto.

Pretende-se continuar a acompanhar e manter o projeto fora do âmbito desta dissertação. Por este motivo, não se tenciona entregar as tarefas futuras a uma equipa de desenvolvimento diferente. Poder-se-á, porém, entregar tarefas como o desenvolvimento de uma interface backoffice ou novas formas de visualização de informação a outros alunos do mestrado em Design e Multimédia da Faculdade de Ciências e Tecnologia da Universidade de Coimbra. Da mesma forma, deseja-se manter as parcerias atuais e continuar criar novas.

Em suma, no futuro pretende-se continuar a melhorar a plataforma de acordo com as necessidades dos utilizadores e o crescimento do volume ou tipo de dados de forma a que o projeto sirva, quão bem quanto possível, o propósito de preservar a história e as memórias do Centro Histórico de Coimbra, seja para recordação, estudo ou criação artística.

Daniel LopesCoimbra, 3 de setembro de 2018

08. Conclusão08. Conclusão

168

Arquivo Digital do Centro Histórico de Coimbra 08. Conclusão

169

Bibliografia □ Chester, D. & Penha, R. (2016). Creative Response-A New Look at

Archiving: The Role Artists Play in Developing Creative Response from Field Recordings of Ethnographic Research. Faculdade de Engenharia da Universidade do Porto.

□ Visão | Três anos depois da unesco, Coimbra relembra memórias. (2016). Obtido 14 de Janeiro de 2018, de http://visao.sapo.pt/actualidade/visaose7e/sair/2016-06-25-Tres-anos-depois-da-unesco-Coimbra-relembra-memorias

□ Norman, D. A. (1988). The Psychology of Everyday Things. Basic Books. □ Magalhães, r. (2011). História da Cidade. Obtido 10 de Janeiro

de 2018, de https://www.cm-coimbra.pt/index.php/histria-da-cidade- menu-municipio-471?task=view&id=1424

□ Leavitt, A. (1961). What Are Archives? The American Archivist, 24(2), 175–178.

□ EAD - Empresa de Arquivo de Documentaï¿½ï¿½o. (1993). Obtido 22 de Janeiro de 2018, de http://www.ead.pt/ead/pt/comunicacao.32/newsletter.53/wano2006.terminologia_arquivistica.a384.html

□ Derrida, J. (1998). Archive fever: A Freudian impression. Chicago: University of Chicago Press.

□ Definição ou significado de arquivo no Dicionário Infopédia da Língua Portuguesa com Acordo Ortográfico. (2017). Obtido 22 de Janeiro de 2018, de https://www.infopedia.pt/dicionarios/lingua-portuguesa/arquivo

□ Definição ou significado de ficheiro no Dicionário Infopédia da Língua Portuguesa com Acordo Ortográfico. (2017). Obtido 22 de Janeiro de 2018, de https://www.infopedia.pt/dicionarios/lingua-portuguesa/ficheiro

□ Fundação Mário Soares. (sem data). | Cc | Index. Obtido 22 de Janeiro de 2018, de http://casacomum.org/cc/

□ Direção Geral do Património Cultural. (sem data). dgpc | Arquivo de Documentação Fotográfica. Obtido 22 de Janeiro de 2018, de http://www.patrimoniocultural.gov.pt/pt/recursos/arquivos-dgpc/arquivo-fotografico/

□ Nielsen, J., & Molich, r. (1990). Heuristic Evaluation of User Interfaces. Em Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 249–256). New York, NY, USA: ACM.

170

Arquivo Digital do Centro Histórico de Coimbra III. Bibliografia

□ Heuristic Evaluation: How-To: Article by Jakob Nielsen. (1995). Obtido 16 de Janeiro de 2018, de https://www.nngroup.com/articles/how-to-conduc-t-a-heuristic-evaluation/

□ Lupton, E. (2003). Science of Typography | Graphic Design Theory. Obtido 16 de Janeiro de 2018, de http://www.graphicdesigntheory.xyz/lupton-scien-ce-of-typography/

□ Maria, J. S. (sem data). How We Read. Obtido 9 de Janeiro de 2018, de http://alistapart.com/article/how-we-read

□ Licko, Z. (2014). Zuzana Licko — fundição digital Emigré. Obtido 9 de Janeiro de 2018, de http://www.tipografos.net/designers/zuzana-licko.html

□ Marcotte, E. (2010). A Book Apart - Responsive Web Design. Foreword by Jeremy Keith.

□ Manobras, & Sonoscopia. (sem data). PortoSonoro. Obtido 8 de Janeiro de 2018, de http://www.portosonoro.pt/

□ Sonoscopia. (sem data). phonambient. Obtido 8 de Janeiro de 2018, de http://www.phonambient.com/

□ Macaulay Library. (sem data). Obtido 8 de Janeiro de 2018, de https://www.macaulaylibrary.org/

□ Biblioteca de Arte / Art Library Fundação Calouste Gulbenkian | Flickr. (sem data). Obtido 8 de Janeiro de 2018, de https://www.flickr.com/photos/biblarte

□ dgpc | Arquivo de Documentação Fotográfica. (sem data). Obtido 8 de Janeiro de 2018, de http://www.patrimoniocultural.gov.pt/pt/recursos/arquivos-dgpc/arquivo-fotografico/

□ Centro de Documentação 25 de Abril - Page Site. (sem data). Obtido 26 de Agosto de 2018, de http://www.cd25a.uc.pt/index.php?r=site/page&-view=itempage&p=100

□ Lyman, P., and Kahle, B. (1998). Archiving digital cultural artifacts. D-Lib Magazine, 4(7)

□ Ross, d. J. (2018). A chromatic signage typeface for vertical and horizontal setting. : djrrb/Bungee. Python. Obtido de https://github.com/djrrb/Bungee (Original work published 2015)

arquivochc.dei.uc.pt

Anexo 1

Lista de 25 plataformas analisadas como casos de estudo

3 de Setembro de 2018Por Daniel Lopes sob a orientação de Pedro Martins e João Bicker



Anexo 2

Brainstorm



2

Anexo 2

3

Anexo 2Arquivo Digital do Centro Histórico de Coimbra

4

Anexo 2

5


6

Anexo 2

7


8

Anexo 2

9


10

Anexo 2

11


12

Anexo 2

13


14

Anexo 2

15


16

Anexo 2

17


18

Anexo 2

19


20

Anexo 2

21


22

Anexo 2


Anexo 3

Processode designda imagemgráfica



2

Anexo 3

3


4

Anexo 3

5


6

Anexo 3

7


8

Anexo 3

9


10

Anexo 3

11


12

Anexo 3

13


14

Anexo 3

15


16

Anexo 3

17


18

Anexo 3

19


20

Anexo 3

21


22

Anexo 3

23


24

Anexo 3

25


26

Anexo 3

27



Anexo 4

Processode designda interface



2

Anexo 4

3


4

Anexo 4

5


6

Anexo 4

7


8

Anexo 4

9


10

Anexo 4

11


12

Anexo 4

13


14

Anexo 4

15


II - estudogeral.sib.uc.pt · Histórico de Coimbra (gravações de Luís Antero), sobre o Google...

Documents

Transcript of II - estudogeral.sib.uc.pt · Histórico de Coimbra (gravações de Luís Antero), sobre o Google...