interfaces tácteis baseadas em...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Interfaces tácteis baseadas emHTML5/CSS3/JavaScript

Ricardo Jorge Maia e Serra

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Teresa Galvão Dias (Professora)

18 de Julho de 2011

Interfaces tácteis baseadas em HTML5/CSS3/JavaScript


Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo júri:

Presidente: M. Eduarda Rodrigues (Professora Auxiliar)

Vogal Externo: Fernando Mouta (Professor Coordenador)

Orientador: Maria Teresa Galvão Dias (Professora Auxiliar)

18 de Julho de 2011

Abstract

The advent of mobile devices has opened new possibilities for personal and profes-sional use. These devices allow to perform tasks, with the advantage of being easilytransportable, so it is interesting to understand which contexts that best applies to theirpotential.

Professional video production, particularly news production, involves several stagesthat are dependent on a set of devices and systems. News agencies have a unique im-portance in preparing and editing news. However, the use of the services provided bythe news agencies, for TV channels and studios, cause inefficiencies that will be furtheranalyzed and detailed.

The proposed solution, newsRail, aims to promote the optimization of this particularbut critical stage of news production workflow. The newsRail is a system of selection,filtering and sorting of various news agencies, such as Reuters or EBU, to be exporteddirectly into editing systems. Tablets allow greater mobility, a factor of increasing im-portance for journalists and reporters, so it would be interesting to develop newsRail forthese devices .With the emergence and maturation of technologies HTML5, CSS3 andJavaScript is required to analyze their advantages over other technologies, such AdobeFlash, for touchables devices.

The thesis was proposed by MOG Solutions, a worldwide leader of solutions in thearea of TV production. The objectives are the development of a functional User Interac-tion prototype newsRail, aimed for mobile and touchables devices, specifically tablets,and analysis through usability testing, the proposed interaction paradigm.

The first part of this report begins by describing the study and workflow of televi-sion production, as well as the technologies mentioned above, framing the reasons forits emergence and maturation. It was also examined the User Centered Design process,which focuses on the needs and constraints of users. In the second part the newsRailsystem is described in detail. Requirements are analyzed, as well the expected workflowand architecture. Then are examined the modules that were developed, the major difficul-ties encountered, and a discussion of the results. Finally in the report, are presented theconclusions and the improvements that could be introduced in the future.

i

Resumo

O aparecimento dos dispositivos móveis trouxe novas possibilidades de utilização parauso pessoal e profissional. Estes dispositivos permitem a realização de várias tarefas,com a grande vantagem de serem facilmente transportáveis, sendo, por isso, interessanteperceber quais os contextos que melhor se aplicam às suas potencialidades.

A produção de conteúdos televisivos, particularmente a produção de notícias, envolvevárias fases que estão dependentes de um conjunto de recursos e sistemas. As agênciasde notícias revestem-se de uma importância única na preparação e edição de uma notícia.Contudo, a utilização dos serviços providenciados pelas agências, por parte dos canais eestúdios de Televisão, acarretam ineficiências que serão analisadas e detalhadas.

A solução proposta, o newsRail, visa promover a optimização desta fase crítica doworkflow de produção de notícias. O newsRail é um sistema de selecção, filtragem e or-denação de notícias de várias agências, como a EBU ou a Reuters, para serem exportadasdirectamente para ambientes de edição. Os tablets permitem uma maior mobilidade, fac-tor de importância acrescida para os jornalistas e repórteres, pelo que se torna evidenteo desenvolvimento do sistema para estes novos dispositivos. Com o advento das tecno-logias HTML5, CSS3 e JavaScript é necessário analisar as suas vantagens relativamentea outras tecnologias, como por exemplo o Adobe Flash, para um ambiente de utilizaçãoorientado por toques e gestos.

A tese foi proposta pela empresa MOG Solutions, líder mundial de soluções na àreade produção de Televisão. Os objectivos passam pelo desenvolvimento de uma protótipofuncional da UI do newsRail, orientado para dispositivos móveis, mais concretamentepara tablets, e à análise, através de testes de usabilidade, do paradigma de interação pro-posto.

A primeira parte do presente relatório começa por estudar e descrever o workflow deprodução de conteúdos televisivos, bem como das tecnologias supracitadas, enquadrandoas razões do seu aparecimento e maturação. É também analisado o processo User Cente-red Design, que se foca nas necessidades e restrições dos utilizadores. Na segunda parte,é descrito em pormenor o sistema newsRail, sendo analisados os requisitos, workflow e aarquitectura a ser usada. Em seguida, são examinados os módulos que foram desenvolvi-dos, indicadas as maiores dificuldades encontradas e é feita a descrição dos testes finais.A finalizar o relatório, são apresentadas as conclusões e as melhorias passíveis de seremintroduzidas no sistema.

ii

Agradecimentos

Gostaria de iniciar o presente relatório por agradecer a todos os que contribuíram,com sabedoria e motivação, para a realização do mesmo, bem como para a formação eevolução do seu autor.

Por conseguinte, deixo os meus sinceros agradecimentos:À Professora Teresa Galvão por toda a sabedoria e auxílio dispensados, sem descurar

a grande disponibilidade e compreensão demonstradas.À empresa MOG Solutions, personificada no Eng.o Pedro Ferreira, Eng.o Rui Amor,

entre muitos outros, pelo apoio e compreensão demonstrados, bem como o pronto auxílioprestado,e em especial ao futuro Eng.o Francisco Brito, por toda a paciência demonstradae pelo conhecimento transmitido, sem o qual não seria possível realizar esta tese.

À minha família, em especial, aos meus Pais e Irmão, por todo o apoio e compreensãodemonstrados, assim como todo o carinho, não só nesta mas também nas anteriores etapasda minha vida.

Aos que me ajudaram na jornada académica que agora termina, contribuindo comamizade e companheirismo.

Aos meus amigos, por todos os momentos que passamos e aos que ainda iremos pas-sar, sem os quais tudo isto não faria sentido.

A todos os anteriormente referidos, e aos que, de algum modo, contribuíram paraelaboração da presente tese, sendo incompreensivelmente esquecidos, o meu mais sinceroe sentido, Obrigado.


iii

“What we have to learn to doWe learn by doing.”

Aristotle

iv

Conteúdo

1 Introdução 11.1 Contexto/Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Motivação e Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Revisão Bibliográfica 72.1 Produção de Vídeo profissional . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 MXF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 software MOG . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 User Centered Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1 Metodologias de desenvolvimento de sistemas interactivos . . . . 202.2.2 Modelos de Desenvolvimento . . . . . . . . . . . . . . . . . . . 232.2.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Tecnologias Multimédia . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.1 Adobe Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.2 HTML 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.3 Análise Comparativa do Flash e HTML 5 . . . . . . . . . . . . . 332.3.4 Frameworks Mobile HTML5 . . . . . . . . . . . . . . . . . . . . 36

3 Especificação do Projecto 393.1 Produção de Notícias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1 Workflow actual . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2 newsRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.2 Workflow do newsRail . . . . . . . . . . . . . . . . . . . . . . . 463.2.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.4 Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2.5 Avaliação Heurística . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Implementação do Projecto 554.1 Abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.2.1 Autenticação e listagem dos vídeos . . . . . . . . . . . . . . . . 574.2.2 Filtragem, ordenação e pesquisa dos vídeos . . . . . . . . . . . . 604.2.3 Pré-visualização dos vídeos . . . . . . . . . . . . . . . . . . . . 62

v

CONTEÚDO

4.2.4 Exportação dos vídeos . . . . . . . . . . . . . . . . . . . . . . . 634.2.5 Configuração do newsRail . . . . . . . . . . . . . . . . . . . . . 64

4.3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . 664.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5 Conclusões e Trabalho Futuro 695.1 Objectivos cumpridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Referências 73

A Guião da Avaliação Heurística 77A.1 newsRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.4 Test Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.5 Test Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.6 Evaluator activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.6.1 Evaluating newsRail (individual) . . . . . . . . . . . . . . . . . . 80A.6.2 Analyzing the results (group) . . . . . . . . . . . . . . . . . . . . 80

vi

Lista de Figuras

2.1 Workflow de produção de Televisão . . . . . . . . . . . . . . . . . . . . 102.2 Estrutura básica do MXF [DWBT06] . . . . . . . . . . . . . . . . . . . . 122.3 Screenshot do software mxfSPEEDRAIL S1000 . . . . . . . . . . . . . . 152.4 Screenshot do software mxfSPEEDRAIL F1000 . . . . . . . . . . . . . . 172.5 Screenshot do software mxfSPEEDRAIL O1000 . . . . . . . . . . . . . 182.6 software baseado na métadora da calculadora digital . . . . . . . . . . . . 202.7 Modelo de design UCD simplificado . . . . . . . . . . . . . . . . . . . . 222.8 Modelo de desenvolvimento Star . . . . . . . . . . . . . . . . . . . . . . 232.9 Adopção das tecnologias web em Dezembro de 2010. . . . . . . . . . . . 242.10 Utilização do HTML 5 para vídeo em iPad . . . . . . . . . . . . . . . . . 312.11 Analogia funcional do HTML, CSS e JavaScript . . . . . . . . . . . . . . 322.12 Validação de um formulário usando JavaScript . . . . . . . . . . . . . . . 332.13 Exemplo do CSS3 usado para simular um ambiente MacOS . . . . . . . . 34

3.1 Workflow de um sistema baseado em tapes [DWBT06] . . . . . . . . . . 393.2 Workflow de um sistema baseado em ficheiros [DWBT06] . . . . . . . . . 403.3 Workflow do newsRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4 Arquitectura do newsRail . . . . . . . . . . . . . . . . . . . . . . . . . . 483.5 Pedidos SOAP e REST do método de login . . . . . . . . . . . . . . . . 50

4.1 Exemplo de um pedido inicial de listagem dos assets . . . . . . . . . . . 594.2 Exemplo de uma listagem inicial de assets . . . . . . . . . . . . . . . . . 604.3 Vistas do newsRail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 Pré-visualização de um vídeo . . . . . . . . . . . . . . . . . . . . . . . . 624.5 Menu de exportação de assets . . . . . . . . . . . . . . . . . . . . . . . 634.6 Estados das exportações . . . . . . . . . . . . . . . . . . . . . . . . . . 644.7 Menu de configuração do sistema . . . . . . . . . . . . . . . . . . . . . . 65

vii

Lista de Tabelas

2.1 Tabela de compatibilidade do <canvas> [Use11] . . . . . . . . . . . . . . 272.2 Tabela de compatibilidade do Web Storage [Use11] . . . . . . . . . . . . 282.3 Tabela de compatibilidade dos Web Workers [Use11] . . . . . . . . . . . 292.4 Tabela de compatibilidade das Offline Web Application [Use11] . . . . . 292.5 Tabela de compatibilidade do <video> [Use11] . . . . . . . . . . . . . . 32

3.1 Tabela com os problemas de usabilidade identificados . . . . . . . . . . . 53

viii

ABREVIATURAS E SÍMBOLOS

Abreviaturas e Símbolos

AAF Advanced Authoring FormatAPI Application Programming InterfaceCRUD Create Read Update DeleteCERN European Organization for Nuclear ResearchCMYK Cyan Magenta Yellow Key blackCGI Computer-generated imageryCPU Central Processing UnitCSS Cascading Style SheetsDRM Digital Rights ManagementEBU European Broadcasting UnionGPS Global Positioning SystemHD High DefinitionHSL Hue Saturation LightHSLA Hue Saturation Light AlphaHTML HyperText Markup LanguageHTTP Hypertext Transfer ProtocolIETF Internet Engineering Task ForceINESC Instituto de Engenharia de Sistemas e Computadores do PortoISO International Standard OrganizationISP Internet Service ProviderIPC Interacção Pessoa-ComputadorMAM Media Asset ManagementMXF Material Exchange FormatNAS Network-attached storageOB Outside BroadcastingPDA Personal Digital AssistantRBGA Red Green Blue AlphaRPC Remote Procedure CallRTP Radio e Televisão de PortugalSDI Serial Digital InterfaceSMTP Simple Mail Transfer ProtocolSOAP Simple Object Access ProtocolSSD Solid-state driveSSL Secure Sockets LayerUCD User-Centered DesignUI User InterfaceVTR Video Tape RecorderW3C World Wide Web ConsortiumWHATWG Web Hypertext Application Technology Working GroupXML Extensible Markup Languagex

Capítulo 1

Introdução

O crescimento das Tecnologias de Informação associado ao aumento da capacidadedos computadores, resultou na presença das TI no nosso quotidiano, designada por Com-putação Ubíqua. Hoje em dia, as pessoas estão em constante interacção com sistemasinformáticos, muitas das vezes nem se apercebendo de tal. A Informática integrou-se nasociedade e não o contrário como acontecia nos inícios das TI.

A Internet é, porventura, nos dias que correm, a tecnologia de telecomunicação maisem voga e com mais potencial a vários níveis. A massificação dos computadores parauso pessoal levou, nos últimos tempos, a uma proliferação da sua utilização. No início daúltima década, assistiu-se a um crescimento das velocidades de transmissão de dados dosfornecedores de serviços de Internet, conhecidos por ISPs. Isto permitiu mais e melhoreswebsites, providenciando serviços inovadores que resultaram numa maior adopção parafins pessoais e profissionais. A comunicação via wireless ajudou também a massificar aInternet, dado que é virtualmente possível estar ligado à Web em todos os pontos do globo.Esta tecnologia despoletou o acesso à Internet através duma vasta gama de dispositivosmóveis, sendo o portátil o caso mais evidente.

A utilização dada aos dispositivos móveis foi-se alterando ao longo dos últimos tem-pos. No início da década passada, as utilizações eram limitadas, focando-se essencial-mente em funções como chamadas ou agendas electrónicas. Com o evoluir destes dis-positivos, assistiu-se a uma maior panóplia de funcionalidades. Hoje em dia é possível,através de um telemóvel, tirar fotografias, aceder à Internet e ao correio electrónico ouusar o GPS como assistente de navegação. Os equipamentos móveis, face às oportuni-dades que oferecem, são cada vez mais computadores de “bolso”. As possibilidades dosdispositivos móveis são enormes, tanto para uso pessoal como profissional. O apareci-mento dos tablets veio revigorar o mercado dos dispositivos móveis, pois são computado-res constituídos por ecrãs tácteis de tamanho médio, com grande potencialidades no que

1

Introdução

à interacção diz respeito.Os equipamentos móveis disponíveis no mercado possuem potencialidades para se

tornarem numa ferramenta de trabalho tão, ou mais importante, que o computador de se-cretária ou a impressora. O uso da Internet, do correio electrónico ou de web servicesnestes equipamentos, possibilita a realização de funções que, muitas das vezes, só po-diam ser executadas dentro do gabinete, cujo processo acarreta ineficiências, elevada de-pendência do posto físico de trabalho, entre outros problemas. A possibilidade de acederremotamente a aplicações através de web services, faz com que se possa operar de formacontínua e independente da localização, usando um dispositivo móvel com acesso à Web.O sucesso na utilização destes dispositivos foi influenciado por um conjunto de factores.Contudo, é necessário um elevado cuidado na realização de aplicações para este tipo deequipamentos, dado que frequentemente carecem de um teclado físico, o seu ecrã é dedimensões reduzidas e têm baixa capacidade de processamento quando comparados comos computadores tradicionais, o que influencia directamente a experiência de utilização.

No mundo em que vivemos, é necessário melhorar continuamente os processos de tra-balho para as organizações se manterem competitivas e a indústria da Televisão não fogeà regra. Tal como as indústrias em geral, esta também foi fortemente afectada pelas TI, oque acarretou mudanças na elaboração e produção de conteúdos televisivos. A melhoriaexponencial das capacidades dos computadores, o decréscimo de custo dos mesmos e acada vez maior velocidade de transmissão de dados por rede, ajudaram à implementaçãoe distribuição dos sistemas de produção baseados em ficheiros, substituindo os sistemastradicionais de tapes. Todavia seria com o formato MXF que os sistemas baseados emficheiros começariam a impor-se e a tornar obsoletos as videotapes e os VTRs.

O formato de ficheiro MXF, combina um par de componentes: metadata e um con-junto de áudio e/ou vídeo chamado de essência. O MXF foi desenhado pelas empresas dosector de produção de vídeo profissional, para garantir que o formato iria ser desenvolvidopara suprir as necessidades e falhas identificadas nos workflows tape-based [Dev02]. Osrequisitos básicos identificados do MXF foram os seguintes: ser um formato aberto, me-lhorar o transporte de metadata e ser livre quanto ao esquema de compressão. Apesar dalarga adopção da indústria e do seu sucesso, o MXF apresenta ainda alguns problemas.

Antes da massificação dos dispositivos móveis, o posto de trabalho era visto como oúnico espaço onde se podiam realizar tarefas no contexto de uma empresa dependentesdas tecnologias de informação. Actualmente é necessário potenciar a mobilidade no ramoempresarial, com vista à adequação da volatilidade e ritmo dos mercados actuais. ATelevisão é um dos casos mais evidentes, particularmente na produção e publicação denotícias. A imprevisibilidade intrínseca das notícias, é uma das causas da mobilidadeque é imposta aos jornalistas. Quando se dá um acontecimento com relevo jornalístico,é necessário que os repórteres se desloquem ao local onde o mesmo ocorreu, usandouma OB Van, que funciona como uma sala de controlo móvel. A produção de material

2

Introdução

televisivo fora do estúdio é conhecido por Outside Broadcasting, no entanto, muitas vezes,as redacções recorrem às agências de notícias como a portuguesa Lusa, ou como a inglesaReuters para terem acesso a conteúdo que, doutra forma, seria fisicamente impossível.

A interacção pessoa-computador é um aspecto importante na utilização eficiente e efi-caz dos equipamentos em geral e pode ser definida como o estudo, planeamento e desenhoda interacção entre os utilizadores e computadores. No caso dos dispositivos móveis, ainteracção pessoa-computador ganha ainda mais relevância. Tipicamente interage-se deforma táctil, o ecrã pode ser visualizado tanto na horizontal como na vertical e o tamanhodo ecrã é reduzido. Devido a estas particularidades, os dispositivos móveis são objecto deum exaustivo estudo na hora de se definir uma aplicação.

Os dispositivos móveis representam assim uma mudança de paradigma na interacçãopessoa-computador permitindo um maior acesso às tecnologias de informação graças àpossibilidade de desenvolver aplicações mais interactivas e com controlos mais naturais.

1.1 Contexto/Enquadramento

A mudança da indústria de vídeo profissional para os sistemas baseados em ficheiros,permitiu a introdução de soluções TI ao longo de todo o processo de produção, desde acaptura passando pelo broadcasting até à fase de arquivamento. A produção de conteúdosaudiovisuais é, hoje em dia, mais dinâmica à luz da forte concorrência existente, dentroe fora da Televisão, em particular na produção e difusão de notícias. A existência de no-ticiários em vários canais, à mesma hora, atribui aos redactores, jornalistas e repórteresuma grande responsabilidade sob pena de perderem audiências, caso a qualidade e exac-tidão das notícias não seja a esperada. Uma falha ou uma notícia incorrecta pode causarenormes prejuízos de publicidade, principal fonte de receitas da Televisão. É percetível oquão crucial é a qualidade do workflow de produção de notícias para os canais e estúdiosde televisão.

A natureza imprevisível das notícias e as óbvias restrições logísticas e económicas,impõe que os jornalistas e redactores recorram a agências de notícias, como a Reuters,Associated Press ou EBU para acederem a informação sobre uma dada notícia. Cadaagência recolhe, prepara e publica as notícias em baskets disponíveis aos redactores doscanais de televisão, que sejam clientes do seu serviço. As notícias são constituídas porum par de vídeo e metadata - assets. Como cada agência tem os seus próprios baskets- torna-se moroso e pouco eficiente, gerir os assets de todas as agências de notícias. Asolução proposta visa corrigir estes problemas. Esta solução é um sistema centralizado depesquisa e selecção de notícias para exportação. Os editores in-house acedem depois aomaterial exportado, fazendo as edições necessárias, para posterior publicação e arquivo.

3

Introdução

Com o surgimento dos tablets, torna-se adequado desenvolver o sistema para estesnovos dispositivos, para assim tirar proveito da mobilidade implícita que estes dispositi-vos oferecem relativamente aos computadores e portáteis tradicionais, sem uma reduçãosignificativa da capacidade de processamento. A Outside Broadcasting, em particular,evoluirá com o conceito do sistema proposto. A reportagem no exterior pode beneficiarde melhoramentos no workflow, devido à utilização de equipamentos móveis tácteis eda capacidade de aceder aos vários baskets das agências de notícias através dum únicosistema, mesmo fora da OB Van.

A presente dissertação foi proposta pela empresa MOG Solutions [FEU11], líder mun-dial em soluções de vídeo baseadas em MXF. A MOG Solutions foi criada em 2002 comoresultado de um spin-off do INESC, por uma equipa de investigadores que participaramactivamente no desenvolvimento do formato padrão do MXF. A empresa dedica-se ao de-senvolvimento de produtos baseados em ficheiros para a área de produção de Televisão.O objectivo da MOG Solutions é investigar, desenvolver e dar apoio a novas soluções paraa indústria de produção e distribuição de conteúdos multimédia [Sol11].

1.2 Projecto

Actualmente os jornalistas necessitam de aceder aos baskets das agências, procurar eassinalar os assets, através de um editor de texto, que desejam utilizar, para depois copiara referência dos mesmos para o editor de vídeo. Como é habitual uma redacção de notíciaster acesso a vários baskets, pode-se facilmente perceber que o workflow não é o melhorpodendo e devendo ser optimizado.

O newsRail é um projecto diferente dos produtos actuais da MOG Solutions, dado quevisa exclusivamente os jornalistas e repórteres. O sistema tem como objectivos melhoraro workflow de selecção, pesquisa e publicação de notícias, tornando-o mais eficiente,centralizado e menos propício a erros por parte dos redactores e jornalistas. O newsRailgere os baskets, actualizando-os automaticamente caso surja um novo asset em algumdos baskets. O utilizador pode pesquisar, filtrar e ordenar os assets, de forma a fazer umaselecção mais rigorosa e precisa dos assets que deseja exportar para o editor de vídeo.

O projecto de dissertação proposto consistiu no desenvolvimento de user interfaces,adaptadas aos tablets, para o sistema newsRail. As tecnologias usadas, após deliberaçãoque pode ser consultado na secção seguinte, foram o HTML5, CSS3 e JavaScript. Foramexecutados testes de usabilidade por forma a avaliar as interfaces implementadas, o quepermitiu melhorá-las tendo em conta as sugestões dos avaliadores. O projecto tambémexigiu o estudo do middleware desenvolvido e utilizado presentemente no newsRail, oBobsled. O Bobsled é uma framework usada nos produtos MOG, e que foi aproveitadapara sustentar o desenvolvimento do newsRail.

4

Introdução

1.3 Motivação e Objectivos

Os processos de trabalho necessitam de estar constantemente optimizados, sob penade exitirem perdas de eficiência e desperdícios de tempo e dinheiro. Em áreas exigentes,como a Televisão, este requisito é ainda mais importante. Hoje em dia o workflow naprodução de notícias tem alguns problemas associados, como, de resto, foi evidenciadono subcapítulo anterior. Com a introdução de tablets associado ao uso de aplicaçõesremotas, permite-se uma maior interoperabilidade bem como maior eficiência e eficácia.

O desenvolvimento de interfaces direccionadas para dispositivos com um paradigmabastante distinto dos tradicionais computadores, constituiu um dos maiores estímulos parao autor.

Os objectivos do projecto de dissertação visam o desenvolvimento de interfaces tác-teis para o sistema newsRail e a realização de testes de usabilidade por forma a aferir ainteracção dos produtos em dispositivos móveis com ecrãs tácteis.

A primeira parte do trabalho envolveu o estudo do estado da arte, e do middleware emque o newsRail se baseia. Actualmente, os produtos da MOG usam a linguagem Flash ecom o surgimento do HTML5 associado ao CSS3 e JavaScript, pretendeu-se avaliar com-parativamente o Flash e o HTML5/CSS3/JavaScript, para aferir qual o melhor paradigmaa ser usado para o newsRail.

A segunda fase do trabalho refere-se à implementação das interfaces para o newsRail.Fazem parte dessa fase a especificação dos requisitos, a análise da arquitectura do sistema,e ainda o desenvolvimento de um protótipo funcional, tendo sido realizados testes deusabilidade.

1.4 Estrutura da Dissertação

Neste capítulo foi feita uma contextualização do problema para um melhor enquadra-mento do projecto. Realiza-se a descrição do projecto, bem como a especificação dosobjectivos do trabalho proposto.

O capítulo seguinte contém a revisão da literatura relativamente à produção de vídeoprofissional, ao formato MXF, às tecnologias web, aos produtos da MOG e à interacçãopessoa-computador. Realiza-se ainda uma comparação entre as tecnologias, por forma aaferir qual a mais adequada ao projecto.

No terceiro capítulo é feita a apresentação detalhada ao projecto a implementar, bemcomo os problemas que este visa colmatar.

O quarto capítulo especifica todos os aspectos e decisões que estiveram envolvidasdurante a implementação do newsRail.

O último capítulo tem como objectivo demonstrar as conclusões retiradas sobre oprojecto realizado. São descritos os pressupostos que foram alcançados, sendo também

5

Introdução

mencionado o trabalho futuro do protótipo desenvolvido, para que o newsRial se tornenuma aplicação totalmente funcional.

6

Capítulo 2

Revisão Bibliográfica

A Televisão é um dos meios de comunicação com maior impacto nas sociedades ac-tuais. O seu grande impacto deve-se, em larga escala, à transmissão e divulgação denotícias. As notícias televisivas fazem parte do quotidiano dos sociedades ocidentais e,muitas vezes, são a única forma de os telespectadores de conhecerem a actualidade doMundo. Apesar da grande aceitação e utilização que a Internet teve, e tem, junto daspessoas, cadeias de informação como a CNN e BBC mantenhem-se firmes na sua tarefaprincipal: transmitir notícias. Nos tempos que correm, as redacções de notícias deparam-se com um grande volume de informação que necessitam de filtrar e editar, tendo por basesistemas de ficheiros como editores de vídeo ou software de captura de sinal analógico.Apesar das melhorias que estes sistemas trazem, acarretam grandes desafios, bem comonovas possibilidades de automatização e interoperabilidade dos workflows.

Os dispositivos móveis estão hoje muito em voga, devido ao recente lançamento doiPad e do iPhone por parte da Apple e à utilização cada vez maior do sistema operativomóvel Android [Web11]. Os tablets são equipamentos informáticos que abrem um novoparadigma de interacção e de produtividade. São mais pequenos e leves que os computa-dores pessoais e os computadores portáteis, permitindo uma maior mobilidade. Os tabletsvieram suprir a falha existente entre os smartphones e os computadores. O modo de fun-cionamento dos tablets é em tudo similar aos smartphones. Funcionam por multi toque,oferecendo uma grande panóplia de gestos e toques para interagir com correio electrónico,fotografias ou vídeos.

Aquando do surgimento da Internet, esta era usada pelos utilizadores como uma fontede informação sobre variados temas. A interacção era pouca ou quase nula e nos raroscasos que existia era efectuada através de guestbooks ou formulários enviados via correioelectrónico. As páginas web eram estáticas, e providenciavam apenas texto, imagens elinks para mais texto e imagens [Wor10].

7


A Web 2.0 é o novo termo aplicado às mudanças verificadas na Internet ao nível dainteracção. Estas mudanças reflectem o surgimento de novas tecnologias que possibili-taram a utilização da Web como uma plataforma interactiva e dinâmica. Foi introduzidopor Tim O’Reilly na conferência O’Reilly Media Web 2.0 e, desde então, o termo é usadopara descrever a actual era da Internet [O’R10]. Esta nova era caracteriza-se por oferecernovas possibilidades entre as quais se destacam as seguintes:

• Web como plataforma – cada vez mais se usam aplicações web que substituem asaplicações tradicionais de desktop, como são os casos do Google Docs, Wikipediae do Gmail;

• Colaboração – a informação não é passada exclusivamente para o utilizador, já queos utilizadores são hoje activos na contribuição de conteúdos para wikis, fóruns oublogs;

• Rich Internet Application – o surgimento de tecnologias como o Adobe Flash, Mi-crosoft Silverlight e Java permitiram a criação de experiências de utilização maisdiversificadas e enriquecedoras;

• User-Centered Design – nova filosofia de design que foca o processo nas necessida-des, limitações e desejos dos utilizadores finais, por forma a melhorar a interacçãoe a experiência de utilização dos produtos.

As Rich Internet Applications (RIA) são tecnologias muito usadas no design de apli-cações web, por oferecerem funcionalidades que hoje são indispensáveis para o utilizador,como é o caso das animações ou dos vídeos.

O presente capítulo irá abordar a produção de vídeo profissional, analisando o work-flow, bem como o formato MXF e o software desenvolvido pela MOG Solutions. Emseguida, é especificada a metodologia user-centered design. Por fim, é dedicado umsubcapítulo às tecnologias do projecto, sendo também feita uma comparação entre oHTML5/CSS3/JavaScript e o Adobe Flash.

2.1 Produção de Vídeo profissional

A indústria da Televisão compreende várias àreas de negócio, e é preciso passar pormuitas fases para que a imagem e o som chegue ao telespectador. Como todas as indús-trias, a Televisão foi-se adaptando às novas exigências e tecnologias que foram surgindodesde a sua invenção. A Televisão foi afectada por outros media, como é o caso do Ci-nema ou mais recentemente da Internet, o que obrigou ao “pequeno ecrã” a batalhar deforma a não perder mercado para outros meios de comunicação. Se no ínicio da difusãoda Televisão, a imagem era a preto e branco e com pouca definição, em pleno século XXI

8


é possível ao telespectador gravar os conteúdos, visualizar mais que um canal ao mesmotempo ou ainda ver programas a três dimensões, tudo isto disponível em alta definição.

Apesar de todas as mudanças que ocorreram na forma como hoje vemos Televisão,certos aspectos pouco se alteraram desde o início da massificação da Televisão, como éo caso da produção de conteúdos televisivos. Tal como acontecia nos primeiros temposde Televisão, em meados do século XX, a criação de um novo programa compreende asfases de planeamento, aquisição de direitos, escrita do guião, casting, filmagens e pos-produção, não obstante o facto de, hoje em dia, todo este processo ser mais complexo edetalhado.

Para a produção de material televisivo eram usadas videotapes, que traziam váriosproblemas ao workflow, como por exemplo, possibilidade de perdas causadas por errosnas videotapes ou pelas normais conversões de formato. Além disto, a edição de vídeoera feita de forma linear, dada a impossibilidade de aceder directamente a um frame dovídeo, sem primeiro bobinar ou desbobinar a cassete [Cor07].

Com o lançamento do primeiro gravador de vídeo digital, em 1991 [Mot11], a Te-levisão começou lentamente a mudar das tradicionais videotapes para os actuais discose consequentemente para os sistemas file-based. Contudo seria com o aparecimento doformato MXF, a detalhar no próximo subcapítulo, que os sistemas baseados em fichei-ros começariam a massificar-se dentro dos estúdios e produtoras de Televisão [Fer10]. OMXF foi desenvolvido com o intuito de uniformizar e agilizar o processo desde a capturaaté ao arquivamento do material, com a vantagem de através das TI, reduzir custos e ma-ximizar os activos, através da disponibilização dos conteúdos nos seus portais web ou emsites de partilha de vídeos como o Youtube ou o Vimeo.

O MXF permite preservar um conjunto de wrappers sobre o áudio e vídeo, fazendocom que a media seja compatível com um maior número de equipamentos. A adopçãodo MXF, associada à ideia conjunta da indústria da Televisão de convergir para formatospadronizados, contribuiu em larga escala para a desejada melhoria da interoperabilidadenos workflows e automação das suas fases.

Hoje em dia, cada vez mais as videotapes estão a ser substituídas por ficheiros. Ossistemas baseados em ficheiros estão cada vez mais presentes no mundo da Televisão[Kov06], apresentando, no entanto, novos desafios a esta indústria. Muitos destes siste-mas baseados em ficheiros, acedem a diferentes armazenamentos, o que traz problemasao nível da duplicação de conteúdos e da diferenciação de formatos para o mesmo con-teúdo, mesmo quando a conversão não é estritamente necessária. Um sistema file-basedideal apresentaria um único e centralizado armazenamento, dado que ofereceria menoresrequisitos e custos de gestão dos conteúdos, assim como um ponto de acesso universal atodos os equipamentos e ambientes do workflow.

A metadata é outro dos aspectos mais relevantes nos media, não sendo a Televisãoexcepção. Permitem uma maior organização da informação e, por consequência, melhor

9


pesquisa e acesso a esta. Com a massificação dos computadores, é hoje possível arma-zenar grandes quantidades de informação, sem implicar um custo significativo associado.No entanto, a falta de uniformização e padrões no uso da metadata, acarreta incompati-bilidades nas descrições da mesma. Além disso, muitas das vezes, a metadata dum dadoconteúdo está dispersa em várias partes, o que torna complicado a sua correcta compilaçãoe definição [Dev02].

2.1.1 Workflow

Figura 2.1: Workflow de produção de Televisão

O workflow duma produção de Televisão pode ser dividida em quatro grandes fases:Captura, Edição, Broadcasting e Armazenamento, Figura 2.1.

A fase de Captura, tal como o nome indica, dedica-se à captura do vídeo. O vídeopode ser capturado através de sinal analógico ou digital e feito o ingest de um digital me-dia, como é o caso dos discos ópticos Sony XDCAM e dos cartões de memória PanasonicP2, ou ainda directamente de uma câmara, através, por exemplo, de uma interface SDI. Oingest do vídeo é tipicamente feito para um servidor.

A Edição corresponde à preparação dos conteúdos disponíveis, para serem depois vi-sualizados pelos telespectadores. Com o advento dos workflows baseados em ficheiros,hoje em dia é efectuado Non-Linear Editing (NLE) [Dev02]. O NLE constitui uma im-portante mudança no paradigma da edição profissional, permitindo aos editores acederdirectamente a qualquer parte dos ficheiros, algo que era bastante moroso e trabalhoso notempo das videotapes.

Após a edição dos conteúdos, passa-se ao Broadcasting dos mesmos. Assim, o soft-ware de edição exporta as sequências para os servidores de playout e/ou servidores dearquivo, sendo os servidores playout que contêm o audiovisual que será difundido atravésda Televisão ou de portais Web.

10


A última fase do processo, destina-se ao Armazenamento dos conteúdos produzidospara um possível uso futuro.

2.1.2 MXF

O formato MXF é um formato aberto direccionado para o intercâmbio de materialaudiovisual com metadados associados. O MXF foi promulgado por um conjunto depadrões da Society of Motion Picture and Television Engineers (SMPTE) [SMPb]. ASMPTE é uma entidade que se dedica à definição de padrões para as indústrias de media,como a Televisão ou o Cinema.

2.1.2.1 História

A história do MXF remonta a meados da década de 90, quando a indústria televisivacomeçou a perceber que os benefícios inerentes ao uso das TI na produção de conteúdosmultimédia, podendo assim minimizar os problemas associados aos sistemas tape-based.O aumento da capacidade de compressão de vídeo digital, aliado à constante melhoriadas velocidades de transmissão de dados e ao decréscimo dos custos de armazenamento,fizeram com que a utilização das TI na produção de conteúdos televisivos se tornasse umarealidade. Além destes factores tecnológicos, foram surgindo novas necessidades dentroda indústria. A NLE estava a tornar-se prática comum, os video servers começavam a seraceites como substitutos fiáveis dos VTRs, a interoperabilidade entre servidores, works-tations e outros dispositivos de criação de conteúdos audiovisuais era visto como crucial,pois traria maior eficiência ao workflow. Outro ponto-chave para o desenvolvimento doMXF foi a necessidade de um transporte melhorado de metadata. O transporte de meta-data durante as fases do workflow, permite uma melhor gestão da informação associada àimagem e áudio, eliminando a introdução repetitiva de metadata.

Em 1996, a SMPTE em conjunto com a EBU, reconheceram a necessidade de um for-mato padrão e aberto para a produção de conteúdos multimédia. Os User Requirementsforam então definidos em colaboração conjunta com a comunidade de desenvolvimentode conteúdos audiovisuais. Um vasto leque de projectos foram levados a cabo pela in-dústria, o que permitiu estudar e detalhar estes requisitos de forma a serem compatíveis eadequados às necessidades reais e às falhas detectadas no workflow. Em 1997 foram des-critas, pelas duas organizações, os User Requirements [For] que o novo formato deveriaendereçar:

• O formato deve guardar a metadata, bem como as componentes de vídeo e áudio;

• O formato deve permitir aos utilizadores começarem a trabalhar no ficheiro, mesmoantes da transferência estar finalizada;

11


• O formato deve providenciar mecanismos que permitam a descodificação da infor-mação do ficheiro;

• O formato deve ser aberto e padronizado;

• O formato deve ser simples, permitindo implementações em tempo real.

2.1.2.2 Estrutura

O MXF é um wrapper, como tal tem como funcções encapsular e descrever comprecisão um ou mais clips. Os clips ou essências podem ser dados, vídeo, áudio ouuma combinação de todos estes componentes. O MXF é agnóstico quanto ao codec,permitindo encapsular AVC, MPEG-2 ou MP3, sendo assim possível a decoders genéricosacederem aos ficheiros de forma consistente. A estrutura de um ficheiro MXF genéricopode ser visualizada na Figura 2.2.

MXF pode ser visto como uma colecção de dois tipos de packages:

• File Packages – representam o source material;

• Material Packages – representam o timeline desejado para output.

Figura 2.2: Estrutura básica do MXF [DWBT06]

Os packages são uma parte constituinte da Structural Metadata. A Structural Metadatadescreve o que é que o ficheiro representa, isto é, a sincronização e o timing entre oscomponentes presentes nas essências. O File Header contém a Structural Metadata, umdos pontos-chave do MXF, o File Body contém a essência e o File Footer representa o fimdo ficheiro, ou seja, funciona como um end of file.

Cada item, dentro do MXF, encontra-se codificado segundo Key-Length-Values (KLVs)[SMPa]. O Sistema KLV permite que descodificadores de MXF e programas de processa-mento ignorem chaves que não reconhecem para assim “saltarem” para o próximo item,através do tamanho do item não reconhecido. Caso reconheçam o identificador, lêem oValue e processam-no. O sistema KLV usa um tripleto para especificar cada elemento:

12


• Key – Identificador do elemento, com 16 bytes;

• Length – Comprimento do elemento;

• Value – Valor do elemento, que pode ser video, imagem ou metadados.

As essências do MXF encontram-se estruturadas nos Essence Containers [SMPc].Os Essence Containers podem ser frame-wrapped, clipwrapped ou custom-wrapped. Asframe-wrapped envolvem cada frame, e o respectivo áudio, dentro de cada KLV. As clip-wrapped reunem todas as frames, ou seja, o clip dentro dum único KLV. Por fim, ascustom-wrapper tal como o nome indica, são definidas e descritas pela aplicação que asusa. A sincronização e descrição das essências é controlada por três packages:

• Material Package (MP) – Representam o timeline desejado para output;

• File Package (FP) – Contém o áudio/video;

• Source Package (SP) – Contém a derivação do FP.

Cada package é identificado por um UMID [UMI]. O conceito dos packages, constituiparte da Structural Metadata do MXF e tem como objectivo, não só especificar a timelinede saída do ficheiro, mas também detalhar informação fulcral como as característicastécnicas da media, entre outras. Outro componente dum ficheiro MXF é a Index Table.A Index Table é um mapa que relaciona uma frame com um byte offset, permitindo assimacesso aleatório facilitado a cada frame do Essence Container. Existem dois tipos deessências: Contanst Byte per Element, onde se incluem codecs como DV, DNxHD ouIMX, ou Variable Bytes per Element, cujo maior representante é o Long GoP MPEG.A definição da Index Table em essências CBE é bastante simples, dado todas as framesterem o mesmo tamanho. No caso das essências VBE a definição é mais complexa, poisnão é conhecido o tamanho de cada frame, antes de se processar a essência. Desta forma,as Index Tables aparecem depois da essência, dado que só é possível mapear as framesdepois de se ter analisado a essência. No caso das CBE, as Index Tables vêm antes dasessências, pois não é preciso processá-las para saber a localização e tamanho de cadaframe [Fer10].

2.1.2.3 Metadata

A metadata é uma componente fundamental do MXF. Tal como o nome indica, ametadata pode ser definida como sendo dados sobre (outros) dados. É usada em váriasindústrias para catalogar o conteúdo e contexto de um conjunto de informação. Existemdois grandes tipos de metadata, com propósitos diferentes, a Structural Metadata e aDescriptive Metadata. A Structural Metadata foi definida anteriormente. A DescriptiveMetadata aloja os dados sobre o material, isto é, o vídeo.

13


No caso específico do MXF, a Structural Metadata informa sobre as essence con-tainers, a identificação dos packages segundo o seu UMID, a história da derivação dainformação, isto é, qual o tipo de device utilizado na captura do sinal.

A Descriptive Metadata normalmente armazena informação geral, como localização,data e legendas, podendo, todavia, conter também informação mais específica, consoanteo contexto em que está inserido o material, como por exemplo, o registo do momento emque ocorreu um golo, ou a sequência de perguntas e respostas numa entrevista.

2.1.2.4 Conclusões

O MXF é uma pedra basilar em que assentam os sistemas baseados em ficheiros,na produção de Televisão. A definição e adopção de padrões desenhados pela, e para,a Televisão, como é o caso do MXF ou do AAF, ajudaram a indústria a dar um saltoqualitativo nos processos de trabalho, além de trazerem associado uma redução de custossignificativa. A preservação e declaração da metadata passou também a ser mais facilitadao que possibilita uma melhor gestão da informação, crucial em plena Era da Informação.Do mesmo modo, foi demonstrado também que o MXF, por si só, não resolve todos osproblemas e que o seu uso potencia o surgimento de alguns.

2.1.3 Software MOG

Os produtos da MOG inserem-se no mercado de produção de conteúdos multimédia.Existem duas gamas de produtos: mxfSPEEDRAIL S1000/F1000 e mxfSPEEDRAILO1000, cada um com as suas finalidades e propósitos. A gama do S1000 e F1000 estádireccionada para operações de ingest. Ingest, no contexto de produção de conteúdosaudiovisuais profissionas, é o processo de transferir e de fazer rewrapping do materialcapturado, por exemplo, directamente duma interface SDI, ou dum disco óptico, para umarmazenamento para ser posteriormente editado e publicado. O mxfSPEEDRAIL O1000dedica-se ao outgest. Outgest é a operação de transferir e transcodificar os conteúdos dumarmazenamento, tipicamente já editados, para os servidores playout, para serem difundi-dos ou para os arquivos, sendo esta a última fase dos vídeos produzidos.

O mxfSPEEDRAIL baseia-se no formato MXF. O mxfSPEEDRAIL S1000 é um sis-tema de captura, permitindo, a partir de um sinal SDI ou HD-SDI, registar a informaçãomultimédia directamente num armazenamento partilhado. O mxfSPEEDRAIL F1000 éum sistema centralizado que permite a transferência de conteúdos entre editores, equi-pamentos, servidores, e outros. O mxfSPEEDRAIL O1000 é um sistema que melhora oworkflow através da integração com os servidores playout, arquivos e portais de distribui-ção web.

O software opera de forma remota e usa o protocolo SOAP, para efectuar a troca deinformação entre servidor e cliente. O formato das messagens é XML, e usa os protocolos

14


HTTP e RPC para a transferência e negociação das mensagens. Para o front-end dosprodutos é utilizada a linguagem Flash da Adobe.

2.1.3.1 mxfSPEEDRAIL S1000

O mxfSPEEDRAIL S1000 é um sistema de captura hardware/software que permite in-gest de inputs SDI e HD-SDI para armazenamento como Avid Unity MediaNetwork/ISIS,discos e-Sata, Omneon MediaGrid, entre outros [Sol10b]. Possibilita também a criaçãode ficheiros proxy, ou seja, cópias de baixa resolução dos ficheiros de vídeo, em formatosMPEG2 352, MPEG4 H.264 e Avid Web Interplay H.263. Os ficheiros de output geradospodem ter os seguintes formatos:

• MXF Op1a, compatíveis com os produtos Sony;

• MXF OPAtom, formato nativo da Avid;

• Quicktime, formato .mov para o Final Cut Pro.

Figura 2.3: Screenshot do software mxfSPEEDRAIL S1000

Vários codecs de vídeo de alta resolução são suportados como é o caso do XDCAM,DVCAM, DVCPRO, AVC, entre outros. No caso dos codecs de áudio, o PCM - 24bits @48KHz é suportado pelo S1000, possibilitando o input de até 12 canais de aúdio embebi-dos. Os maiores benefícios do S1000 são os seguintes:

15


• Edição enquanto captura o sinal - permite que, enquanto os ficheiros estão a ser in-geridos para o armazenamento, o editor possa trabalhar sobre eles, poupando tempo:

• Suporte multi formato e multi resolução;

• Multi destino - permite escrever em vários armazenamentos ao mesmo tempo;

• Gestão e automação dos processos - suporta a gestão feita pelas MAMs, que consis-tem em tarefas e decisões de gestão relacionadas com todo o workflow da produçãode conteúdos multimédia.

A interface do S1000, na Figura 2.3, disponibiliza as seguintes funcionalidades:

• Video Monitor - onde é visualizado o ficheiro vídeo enquanto se captura o mesmo;

• Controlo VTR - permite o controlo sobre o vídeo através de butões de Play, Stop,Forward, entre outros;

• Visualização do timecode;

• Editor de layouts - possibilita o redesenho da interface;

• Autenticação dos utilizadores.

2.1.3.2 mxfSPEEDRAIL F1000

O mxfSPEEDRAIL F1000 é um sistema file-based, que permite aos profissionais in-gerir HD, SD e ficheiros proxy como por exemplo Sony XDCAM, Panasonic P2 emvários tipos de armazenamento e equipamentos. O sistema detecta quando surgem novosconteúdos nos devices ou nas pastas que estão a ser monitorizadas e exporta usando oswrappers Avid OPAtom ou MXF OP1A, para vários tipos de armazenamento como AvidUnity MediaNetwork, Avid Unity ISIS ou um disco e-Sata.

Os inputs suportados para exportação são:

• XDCAM;

• DVCPRO, DVCPRO 50, DVCPRO HD;

• MXF OP1A;

• AVC-I;

• QuickTime.

Como se trata de um sistema de ingest, tal como o S1000, o mxfSPEEDRAIL F1000também oferece ao utilizador:

• Edição enquanto captura o sinal;

16


Figura 2.4: Screenshot do software mxfSPEEDRAIL F1000

• Multi-destino - permite escrever em vários armazenamentos ao mesmo tempo;

• Gestão e automação dos processos - suporta a gestão feita pelas MAMs, que consis-tem em tarefas e decisões de gestão relacionadas com todo o workflow da produçãode conteúdos multimédia.

A principal diferença entre o F1000, na Figura 2.4, e o S1000 é a fonte dos inputs: oF1000 destina-se a ingest de ficheiros, enquanto o S1000 destina-se a ingest de interfacesSDI e HD-SDI.

2.1.3.3 mxfSPEEDRAIL O1000

O mxfSPEEDRAIL O1000 é um sistema hardware/software de outgest, isto é, permiteexportar e publicar, sobre sequências Avid em ficheiros do formato MXF OP1a [Sol10a].Os ficheiros podem ser exportados para um conjunto de armazenamentos como o AvidUnity MediaNetwork/ISI eo, Omneon MediaGrid. Opcionalmente, podem ser geradasversões web dos ficheiros para posterior publicação na Internet.

Os inputs suportados para exportação são mencionados em seguida:

• IMX 30/40/50;

• DVCPRO, DVCPRO 50, DVCPRO HD;

• DNxHD;

17


Figura 2.5: Screenshot do software mxfSPEEDRAIL O1000

• AVC-I;

• MPEG Long GOP.

Através da exportação, os ficheiros gerados podem ser:

• MXF OP1a para publicação;

• MP4 (H.264) para visualização online;

• Proxy H.263 para ficheiros proxy.

O sistema suporta dois modos de funcionamento: o editor de vídeo, e o browser,através de web services, que ser visto na Figura 2.5. Os principais beneficios do O1000são:

• Compatibilidade multi formato e multi resolução;

• O uso do editor de vídeo para operações de outgest deixa de ser necessário;

• Inexistência de perda de qualidade relativamente ao original;

• Possibilidade de outgest em várias sequências Avid ao mesmo tempo;

• Automação da exportação das sequências Avid;

• Automação do workflow, devido à fácil integração com os servidores playout, ar-quivos e portais de distribuição online.

18


2.1.3.4 Conclusões

A MOG, com o mxfSPEEDRail, oferece um sistema de integração de todas as fases dacadeia de produção - captura, edição, distribuição e arquivo. Os produtos mxfSPEEDRailsão dos mais avançados no mercado de sistemas file-based, tendo ganho inúmeros prémiosda especialidade [Tec].

2.2 User Centered Design

A Interacção Pessoa-Computador é a ciência que estuda a relação entre os utilizadorese os equipamentos, e comporta o estudo, planeamento e desenho da interacção entre osdois actores [RSP02]. Os objectivos da IPC são desenvolver produtos:

• Fáceis de aprender;

• Eficientes de utilizar;

• Enriquecedores ao nível da experiência de utilização.

Perceber e conceptualizar a interacção é um aspecto de extrema importância na IPC[RSP02]. Primeiro é necessário analisar o problem space, ou seja, conceptualizar o quese irá criar e o porquê de se estar a criar. Para analisar o problem space, é preciso:

• Conhecer o que se deseja criar - uma nova interface para um produto existente, comoé o caso deste projecto, uma nova forma de completar uma tarefa, etc.;

• Definir as assunções - o que é que se assume que o produto vai providenciar;

• Definir as afirmações - o que é que se pode afirmar em relação ao produto.

O modelo conceptual é uma descrição de alto nível de como o sistema funciona eestá organizado. Metáforas e analogias são usadas para perceber qual o(s) objectivo(s) dosistema e como este funciona. Existem duas formas de descrever os modelos conceptuaisbaseados:

• Em actividades: através de instruções, conversação, manipulação, navegação ouexploração;

• Em objectos (metáforas): através de folhas de cálculo, desktops, árvores, calculado-ras - Figura 2.6, entre outros.

Normalmente os sistemas são descritos por modelos conceptuais híbridos como é ocaso do Windows onde existe manipulação de menus, ícones e pastas, bem como instru-ções através de atalhos do teclado ou pela introdução de comandos na linha de comandos.

19


Os sistemas também podem ser definidos por metáforas, para uma maior facilidadede aprendizagem de um novo sistema, baseando a interacção do mesmo em modelos bemconhecidos. No entanto, podem surgir problemas devido às limitações do designer. Osutilizadores podem usar o sistema de forma literal à metáfora ou, dos objectos em que ossistemas se baseiam, já que muitas das vezes não oferecem todas as formas de interacçãolevando à quebra de regras e consequente falha no modelo.

2.2.1 Metodologias de desenvolvimento de sistemas interactivos

Desenvolver um projecto implica ter uma metodologia por forma a atingir os objecti-vos propostos. No início dos anos 80, as metodologias eram baseadas na crença que osprocessos cognitivos eram quantificáveis e previsíveis resultando em interfaces pouco in-tuitivas e onde os utilizadores não tinham qualquer envolvimento durante todo o processode design. As primeiras metodologias obrigavam os utilizadores a envolverem-se como sistema, e não o contrário. As metodologias actuais focam-se no constante feedbacke interacção dos utilizadores com os designers culminando em interfaces mais intuiti-vas e agradáveis, pois os sistemas interagem da forma como os utilizadores preferem,tornando-os mais eficientes e efectivos.

Figura 2.6: software baseado na métadora da calculadora digital

A metodologia User Centered Design (UCD), Figura 2.7, está muito em voga nostempos que correm [RSP02]. A filosofia por detrás desta metodologia baseia-se, tal comoo nome indica, no envolvimento dos utilizadores durante todo o processo. Os princípiosem que a UCD assenta são:

20


• Focar desde o início nos utilizadores e tarefas;

• Medição empírica - observar, registar e analisar o comportamento dos utilizadoresquando expostos a manuais, protótipos e cenários;

• Design iterativo - o processo de design é cíclico e em todas as iterações o processocaracteriza-se por: primeiro, desenhar a interface; segundo testar a interface com osutilizadores; terceiro análisar os resultados do teste e por fim repetir do processo.Este termina quando a interface é satisfatória para os utilizadores envolvidos.

Os utilizadores envolvidos no processo de design têm um papel fundamental, poispermitem gerir a expectativa de uma melhor forma e também pelo sentido de propriedadeque os utilizadores adquirem ao estarem envolvidos no desenvolvimento do produto. Asactividades principais do processo UCD são:

1. Perceber as restrições/contexto;

2. Analisar os utilizadores;

3. Analisar as tarefas;

4. Alocar as tarefas;

5. Definir o(s) critério(s) de usabilidade;

6. Desenhar a interface - incluindo ajuda e documentação;

7. Construir e testar protótipos;

8. Construir e testar a aplicação;

9. Lançar, actualizar e manter a aplicação.

A primeira actividade consiste em definir o tipo de utilizadores e o tipo do produto aser desenvolvido. Na primeira actividade, é também fundamental definir as restrições aonível do custo e planeamento, bem como as restrições ao nível de software/hardware.

A segunda actividade está relacionada com o estudo das características, capacidades enecessidades dos utilizadores.

A terceira actividade dedica-se ao estudo das tarefas a serem executadas pelo produto.A comunicação e a observação dos utilizadores a executarem as tarefas é essencial parauma melhor análise. A classificação das tarefas em critérios como frequência de utiliza-ção, complexidade e experiência necessária para completar as mesmas é importante paraperceber como deve o sistema abordar determinada tarefa.

A alocação de tarefas implica decidir quem ou o quê está talhado para realizar deter-minada tarefa. O produto deve ter mecanismos que realizem partes da tarefa, da mesma

21


Figura 2.7: Modelo de design UCD simplificado

forma que o utilizador deve ter mecanismos para completar as tarefas. Um exemplo é umsistema de login, onde o sistema regista e apresenta o username ao utilizador e o utilizadorescreve a palavra-passe para se validar.

Na quinta actividade, são definidos os critérios de usabilidade, ou seja, as métricasque serão usadas para avaliar a usabilidade do produto. Os critérios podem ser tão vastoscomo executar uma tarefa em menos de "x"segundos ou guardar um documento onlinepassado "y"segundos da última modificação.

A sexta actividade consiste no design da interface. Esta actividade implica ter feed-back por parte dos utilizadores, apresentando protótipos aos utilizadores envolvidos noprocesso, fazendo uma observação à utilização bem como a realização de um pequenoquestionário. É um processo iterativo dado que o feedback tem um papel importante noredesenho do produto, pois só assim se consegue ter um produto utilizável.

A construção e teste de protótipos é uma actividade que se destina a criar e a testarprotótipos baseados na tarefa anterior. Tal como o design da interface, é um processoiterativo onde são primeiro usados protótipos de baixa fidelidade criados através de, porexemplo, papel e caneta e depois são construídos protótipos de alta-fidelidade que já sãosemelhantes ao produto final. A evolução dos protótipos só é possível através de testescom os utilizadores por forma a obter feedback objectivo e subjectivo.

A oitava actividade é dedicada ao desenvolvimento e teste da aplicação final. Paratal é imprescindível repetir os ciclos de teste e desenvolver o produto de acordo com osresultados dos mesmos. A atenção deve estar focada primeiro nas funcionalidades e sódepois na interface.

A última actividade é o lançamento, actualização e manutenção do produto. Para o

22


produto ser competitivo é necessário actualizá-lo e mantê-lo, não só a nível das funciona-lidades mas também ao nível do design.

2.2.2 Modelos de Desenvolvimento

Os modelos de desenvolvimento de software especificam como as actividades se in-terligam, funcionando como ferramentas de gestão de projectos. Existem vários modeloscomo Modelo em Cascata, Modelo em Espiral ou modelos mais ágeis como Extreme Pro-gramming ou Scrum. Além dos modelos de desenvolvimento de software, que se aplicamà produção de software, existem também modelos de sistemas de interacção baseados naabordagem User Centered Design. São os casos do modelo Star, Soft Systems Metho-dology ou o Participatory Design. Estes modelos são complementares aos modelos dedesenvolvimento de software acima definidos, e descrevem a forma como os princípios eas actividades da UCD se relacionam.

Figura 2.8: Modelo de desenvolvimento Star

O modelo Star, ilustrado na Figura 2.8, é orientado ao desenvolvimento de sistemasinteractivos utilizáveis pelas pessoas. Foi criado em 1989 por Hartson e Hix, e tem aavaliação como principal actividade. Não existe uma ordem sequencial de actividades aserem executadas, podendo começar-se com qualquer actividade. Este modelo surgiu deestudos empíricos de designers realizados pelos investigadores.

2.2.3 Conclusões

O UCD é uma das novas forças da Web 2.0 pois os seus príncipios e actividadesfocam-se nos utilizadores e não nos sistemas, o que permite desenhar aplicações web maisapelativas. A metodologia User Centered Design resultou do esforço na mudança dosparadigmas de interacção e design, facilitando o uso dos sistemas e consequente adopção,particularmente das aplicações na web.

23


2.3 Tecnologias Multimédia

2.3.1 Adobe Flash

O Flash é um tecnologia multi plataforma introduzida em 1996 pela Macromedia.Actualmente é distribuída e desenvolvida pela Adobe Systems, empresa responsável pelodesenvolvimento e actualização de software como o Adobe Photoshop, Adobe InDesignou o Adobe Premiere Pro. O Adobe Flash permite a introdução de vídeos, animações,jogos em aplicações web [Sys11a]. Utiliza desenho vectorial ou bitmaps para animar osconteúdos. Os ficheiros Flash são, tradicionalmente, em formato SWF e necessitam doplug-in Adobe Flash Player instalado para se tirar partida da tecnologia. O Adobe Flashcontém a linguagem orientada a objectos ActionScript, usada como suporte ao desenvol-vimento de aplicações web com Flash, um pouco à semelhança do JavaScript, dado queambas provêm do ECMAScript.

Figura 2.9: Adopção das tecnologias web em Dezembro de 2010.

É uma das tecnologias web mais presentes nos desktops. Para se tirar partido dasaplicações desenvolvidas em Flash é necessário ter-se o Adobe Flash Player instalado.O Adobe Flash Player está disponível para plataformas Windows, Mac OS, Android ouSymbian, entre outras. Segundo um estudo, que pode ser visto na Figura 2.9, realizadopela empresa Millward Brown em Dezembro de 2010, o Flash Player está presente emquase 100% dos computadores, o que espelha bem a proliferação da tecnologia da Adobe.

A última versão do Adobe Flash Player é a 10.2 [Sys11b], e disponibiliza novas funci-onalidades que vêm responder aos apelos dos programadores. O suporte dos dispositivosmóveis baseados em Android, BlackBerry e Palm webOS é uma das grandes novidades,pois permite interagir através de multi toque e gestos, introduzir texto pelo teclado vir-tual, ler os valores do acelerómetro para controlar, por exemplo, a orientação do ecrã. É

24


possível também usar o codec H.264 nos vídeos, o que traz uma melhoria de performanceessencial para os dispositivos móveis. Novos efeitos estão disponíveis como o efeito 3D,blur ou glow para a criação de experiências cinemáticas.

A utilização do Flash para a visualização de vídeo é uma das funcionalidades maisusadas. Está presente em sites como Youtube.com, metacafe.com, Yahoo! video ou Reu-ters.com. O formato de vídeo é .flv ou .fvp. O codecs video suportados além do H.264são:

• Sorenson Spark

• On2 VP6

A protecção de conteúdos, é uma das razões para a adopção do Flash na visualizaçãode vídeos, dado que permite aos administradores evitarem a cópia de informação. Apossibilidade de ver um vídeo em full screen, é outros dos benefícios do Flash. Desdea versão 10.1, o Flash permite aceleração por hardware, através do GPU, diminuindo ooverhead.

O Adobe Flash é uma tecnologia bastante sólida e massificada nos computadores parauso pessoal. As suas potencialidades são enormes, e qualquer browser é suportado peloAdobe Flash Player, o que transforma o Adobe Flash numa tecnologia ganhadora.

2.3.2 HTML 5

2.3.2.1 História

A linguaguem markup utilizada na World Wide Web é o HyperText Markup Lan-guague. Uma linguagem markup é definida por um conjunto de tags e o HTML utilizadiferentes tipos de tags para descrever uma página web. Uma tag é um elemento descritorentre < >. Os documentos HTML são interpretados pelos browsers, que posteriormentecriam uma página web com elementos visuais e/ou auditivos associados. Uma página webpode conter vários elementos multimédia como imagens, texto, animações, entre outros.

O HTML foi escrito por Tim Berners-Lee em 1989 no European Organization forNuclear Research, mais conhecido por CERN. Surgiu da necessidade de colaboração nainvestigação da Física de Partículas [W3C98]. Nos primeiros anos, o HTML sofreu mui-tas mudanças e revisões, primeiro no CERN e depois no Internet Engineering Task-Force(IETF). Em 1995 foi lançado o HTML 2.0 pela IETF.

Em 1994 a criação da World Wide Web Consortium (W3C), com o purpósito de de-senvolver protocolos e criar guidelines para assegurar o crescimento a longo-termo daInternet, o desenvolvimento do HTML passou da IETF para a equipa da W3C, lideradapor Tim Berners-Lee. O HTML passou por várias versões, até ser publicada como umstandard internacional ISO/IEC. A versão em causa data de Maio de 2000, sendo a versao4.01

25


O HTML 5 começou a ser desenvolvido em Junho de 2004 pela W3C em conjuntocom a WHATWG. O primeiro draft do HTML5 foi lançado em Janeiro de 2008. O HTML5 ainda está a ser desenvolvido e encontra-se em fase Last Call, segundo a WHATWG[WHA11a]. Diferentes partes do HTML 5 encontram-se em diferentes níveis de matu-ridade. Existem funcionalidades que podem já ser usadas como é o caso do <canvas> eexistem outras que ainda estão a ser desenvolvidas e podem mudar. As fases de desenvol-vimento, definidas pela WHATWG, para as funcionalidades são:

• First Draft - fase inicial;

• Working Draft - fase inicial, mas mais madura relativamente ao First Draft;

• Last Call - fase bastante avançada, mas existe feedback a ser processado;

• Awaiting implementation feedback - fase avançada, mas pode ser alterada em funçãoda resposta dos programadores;

• Implemented and widely deployed - fase de conclusão.

HyperText Markup Languague 5 é a próxima geração da linguaguem markup standardutilizada nos websites [Ove11]. O HTML 5 é uma open plataform tal como as versõesanteriores, não necessitando de software licenciado para se usufruir. A único requisitoé usar um browser recente, tal como o Google Chrome ou o Mozilla Firefox. Os docu-mentos HTML 5 além de incluírem tags para definir textos e imagens, possibilitam novoselementos como vídeo e áudio. As novidades desta nova linguagem não se esgotam naadição de vídeo e áudio. Apesar de nem todos os browsers suportarem o HTML 5 to-talmente, dado que este ainda está a ser desenvolvido, alguns browsers já suportam umconjunto interessante destas novidades. De seguida, serão apresentadas as novas funcio-nalidades que o HTML 5 oferece actualmente, e no final de cada uma será apresentada acompatibilidade desse elemento com os browsers actuais.

2.3.2.2 Canvas

O elemento <canvas> é definido como um bitmap dependente da resolução que podeser usado para renderizar gráficos, jogos ou outros elementos visuais em tempo real[Pil10]. O <canvas> é, nada mais nada menos, que um rectângulo que pode ser mani-pulado através do JavaScript para se desenhar algo. O rectangulo é um sistema bidimen-sional de coordenadas X e Y com tamanhos x1 e y1, sendo o ponto (0,0) o canto superioresquerdo e o ponto (x1,y1) o canto inferior direito. Pode-se pensar no <canvas> como oMicrosoft Paint, sendo o JavaScript o conjunto de ferramentas que possibilita o desenhona superfície branca.

26


O <canvas> tem muitas potencialidades pois possibilita a construção de formas, cami-nhos, arcos, curvas quadráticas e de bezier além de outros elementos. É também possíveladicionar efeitos aos gráficos como gradientes, sombras ou transparências.

As animações também estão presentes no HTML 5, através do <canvas>. Isto é feitoatravés do redesenho das formas, para assim dar a sensação de estarem animadas. Con-tudo a falta de uma API específica para animações, faz com que se tenha de estar cons-tantemente a actualizar os timers e outros eventos.

Além do desenho de formas no espaço <canvas> é também possível inserir texto. Pos-sibilita o controlo da fonte (tamanho, estilo, altura, entre outros), o alinhamento do texto,e o baseline atributo controla o local onde o texto é desenhado relativamente ao ponto departida. Este texto não pode, contudo, ser modificado usando os atributos tradicionais doCSS.

O <canvas> encontra-se actualmente na fase de desenvolvimento Working Draft.

Tabela 2.1: Tabela de compatibilidade do <canvas> [Use11]

IE Mozilla Apple Google Opera iOS Android9 Firefox 4 Safari 5 Chrome 10 11 Safari 4.2 Browser 2.3

Suportado X X X X X X XNão suportado

2.3.2.3 Web Storage

O armazenamento local de informação nas aplicações web, era assegurado, até à poucotempo, unicamente pelos Cookies. Os Cookies têm contudo algumas falhas:

• O tamanho dos Cookies é de cerca de 4KB, que era adequado nos inícios da Web,mas actualmente é insuficiente pois as velocidades de Internet são bastante maisrápidas e as aplicações web são mais pesadas que nunca, não sendo possível, muitasdas vezes, armazenar toda a informação necessária;

• Os Cookies são enviados em todos os pedidos HTTP, transmitindo informação re-dundante o que leva a um desperdício da velocidade de Internet;

• Caso o website não esteja encriptado segundo os protocolos SSL, os Cookies sãoencaminhados de forma desencriptada levando a um risco de segurança.

O Web Storage é definido como o armazenamento de informação persistente de pareskey-value nos browsers [Pil10].O Web Storage veio colmatar estas falhas. Possibilita oarmazenamento até 5 MB de informação nos browsers Opera, Google Chrome, MozillaFirefox, e até 10 MB no Internet Explorer 9. A informação não é sempre enviada para o

27


servidor, ficando unicamente acessível no cliente. Apesar do servidor não poder escreverdirectamente no Web Storage pode enviar pedidos de escrita e leitura quando necessários,através de JavaScript.

Existem duas formas de armazenamento de informação: local e sessão. O armazena-mento local caracteriza-se por ser exclusivo para cada domínio e a informação disponívelpersiste depois do browser ser fechado. O armenazenamento de sessão é usado para cadapágina e domínio e tem uma duração limitada ao tempo de vida da página.

O Web Storage encontra-se na fase Working Draft.

Tabela 2.2: Tabela de compatibilidade do Web Storage [Use11]


Suportado X X X X X X XNão suportado

2.3.2.4 Web Workers

A adição dos Web Workers é uma funcionalidade bem-vinda num mundo cada vezmais tecnlógico. Web Workers são, à imagens das threads, unidades de processamentomais pequenas que permitem executar scripts de forma paralela [W3C11b]. Thread édefinido como a forma de dividir um processo em duas ou mais tarefas para serem assimrealizadas concorrentemente.

Os Web Workers permitem que, enquanto uma página está a ser carregada, o utilizadorconsiga navegar na página web, clicar ou fazer scroll na mesma. Tal é interessante quandotemos uma página com várias operações a serem efectuadas simultaneamente, como cál-culos matemáticos, carregamento de múltiplos vídeos HTML 5, e ainda o desenho de umaanimação complexa usando o <canvas>.

Existem dois tipos de Web Workers: dedicated workers e shared workers. Os primei-ros, depois de criados, estão conectados com o seu criador, contudo podem comunicarcom outros workers. Os shared workers uma vez criados, qualquer script em execução namesma origem pode obter uma referência para o worker e comunicar com ele.

O uso dos Web Workers deve ser restringido, pois a sua utilização implica gastosavultados de memória e CPU. Deve ser usado um número limitado de Web Workers, poisum elevado número de Web Workers pode ter um resultado inverso ao esperado, ou seja,a performance pode-se degradar. Os Web Workers encontram-se na fase Working Draft.

28


Tabela 2.3: Tabela de compatibilidade dos Web Workers [Use11]


Suportado X X X XNão suportado X X X

2.3.2.5 Offline Web Applications

Enquanto se está online os recursos, onde se incluem páginas HTML, imagens ouficheiros CSS, são descarregados para visualização destes no browser. Quando se ficaoffline a meio do carregamento da página web, o mais provável é não conseguirmos visu-alizar e interagir com os recursos até a ligação à Internet volte. Com o HTML 5 pode-seagora aceder offline ao correio electrónico, continuar a jogar um jogo online em Flash porexemplo ou acabar de ver um vídeo.

As Offline Web Applications funcionam através dum ficheiro manifest que lista osficheiros necessários para a aplicação web funcionar em offline [Pil10]. O browser, casosuporte esta funcionalidade, guarda uma cópia dos ficheiros listados para serem usados emmodo offline. Com o Web Storage, é possível guardar localmente informação e estadosassociados aos recursos que usamos enquanto trabalhamos offline, para depois enviar esincronizar com o servidor. O Google Gears ou o Google Docs são exemplos do uso deOffline Web Applications.

A Offline Web Application encontra-se na fase Working Draft.

Tabela 2.4: Tabela de compatibilidade das Offline Web Application [Use11]


Suporte total X X X X X XNão suportado X

2.3.2.6 Video

A visualização de vídeos e filmes na Internet já está presente há alguns anos. O sitede streaming de vídeos Youtube.com é um dos casos de sucesso mais evidentes. Os ví-deos na Internet são tipicamente disponibilizados através de plug-ins como o QuickTime,RealPlayer ou o Adobe Flash, que por sua vez, estão integrados nos browsers. O You-tube.com, por exemplo, dispõe os seus vídeos aos utilizadores através do Adobe Flash. Aorigem destes plug-ins surgiu da necessidade de ver vídeos online e da falta de suporte doHTML da altura. Com a introdução do HTML5 e o aparecimento da tag <video>, é agora,em teoria, possível ver vídeos sem ser necessário utilizar um dos plug-ins mencionados

29


acima, pois o <video> ainda está em desenvolvimento e o seu uso ainda não é suportadopor todos os browsers, como é o caso do Internet Explorer [Pil10].

Um vídeo é a combinação de um formato de vídeo ou container, que define como ovídeo é guardado, e um codec de vídeo e áudio que não é mais que um algoritmo quedefine a forma como vídeo e áudio está codificado, respectivamente.

Existem vários containers dos quais se apresentam alguns de seguida:

• MPEG4 - formato baseado no container Quicktime .mov. Tem como extensões .mp4ou .m4v;

• Flash video - até hà pouco tempo, era o único formato compatível com o AdobeFlash. Agora o Adobe Flash também suporta MPEG4. Tem como extensões .flv e.f4v;

• Ogg video- é um formato grátis, open standard, suportado nativamente por browserscomo Mozilla Firefox, Google Chrome e Opera;

• WebM - formato open standard desenvolvido pela Google para uso em vídeo HTML5.Este formato é baseado no formato Matroska. Tal como o Ogg, é suportado nativa-mente pelo Mozilla Firefox, Opera e Google Chrome. A Adobe já anunciou que irásuportar este formato na próxima versão Flash (citação). A extensão associada aoWebM é .webm;

• AVI - Um dos formatos mais antigos, desenvolvido inicialmente pela Microsoft.Contudo tem limitações face aos outros formatos, como a falta de metadata incor-porada ou, a falta de suporte para os codecs mais recentes.

Os codecs, tal como descrito anteriormente, funcionam como codificadores e desco-dificadores do vídeo. Existem dois tipos de codecs: lossy e lossless. Os codecs lossy,reduzem a qualidade relativamente ao original, para assim reduzir o tamanho do ficheiro.Muitas das vezes é difícil notar as diferenças entre o original e o ficheiro codificado. Estescodecs são muito populares na Internet pois são mais adequados à visualização de vídeos.Os codecs lossless guardam a qualidade original do vídeo, o que implica um tamanhomaior relativamente aos codecs lossy. Dado a grande utilização dos codecs do tipo lossyno streaming de vídeo online, apenas estes serão analisados em maior detalhe.

O HTML5 suporta um conjunto alargado de codecs lossy, como H.264, Ogg Theora,Dirac, VP8, entre outros. Os mais importantes são o VP8, Ogg Theora e H.264, pois sãoos suportados pelos browsers mais usados como o Firefox, Chrome ou Opera, contudonão existe um codec de vídeo suportado por todos os browsers, o que acarreta problemasde compatibilidade se só for usado um codec no streaming.

O VP8 é um codec aberto, desenvolvido pela Google no seguimento do projectoWebM. No formato WebM, o VP8 é o codec vídeo usado. Este codec foi inicialmentedesenvolvido para ser o codec padrão na visualização de vídeos através do HTML 5.

30


Figura 2.10: Utilização do HTML 5 para vídeo em iPad

O Ogg Theora é um codec desenvolvido para se usar com o formato Ogg. Foi inicial-mente o formato e o respectivo codec, desejado pela W3C para ser a plataforma padrão devídeo. No entanto, devido a uma série de acontecimentos, deixou de ser o formato/codecstandard do HTML 5.

O H.264 é um codec proprietário suportado e apoiado por empresas como a Adobe,Apple ou Microsoft através do Flash, Safari, Internet Explorer respectivamente. É umcodec bastante usado no streaming de vídeo por sites como Youtube.com, Vimeo.com.Apesar das suas qualidades, o H.264 não pode ser o codec padrão do HTML 5 devido àssuas licenças pagas.

Como os vídeos não são tão úteis sem áudio, este é uma parte integrante dos vídeos.Existem alguns codecs de áudio suportados pelo HTML 5 como o Ogg Vorbis, MPEG-1Audio Layer 3 mais conhecido por MP3.

Devido à existência de uma quantidade significativa de containers e codecs e ao desen-volvimento ainda em curso do HTML 5 e mais especificamente do elemento <video>, énecessário escolher os formatos/codecs adequados para a aplicação ser o mais compatívelpossível.

31


O elemento <video> encontra-se na fase Working Draft.

Tabela 2.5: Tabela de compatibilidade do <video> [Use11]


Suporte total X X X X X X XNão suportado

2.3.2.7 JavaScript e CSS3

Figura 2.11: Analogia funcional do HTML, CSS e JavaScript

O HTML 5 por si só, não consegue implementar aplicações web, pois necessita doJavaScript e do CSS, como pode ser visto na analogia presente na Figura 2.11. O HTMLé uma linguagem que define os conteúdos, precisando destas tecnologias para adornar ecompletar as aplicações quanto à apresentação e interacção.

O JavaScript é multi-plataforma, e é uma linguagem orientada a objectos. A suautilização deve ser complementada com outras tecnologias, como o caso do HTML 5para aplicações web. O Javascript inclui um conjunto de objectos para manipulação comoArrays ou Dates, e um conjunto de elementos como operadores, estruturas de controlocomo whiles, fors e ifs, statements entre outros. O JavaScript é baseado na linguagemECMAScript, tal como o ActionScript que tem as mesmas finalidades que o JavaScriptmas para plataformas Flash.

A utilização do Javascript na Internet é normalmente efectuada pelo cliente, por exem-plo, através da validação dos valores de input nos formulários, Figura 2.12. Pode tambémser usado pelo servidor, para comunicar com a base de dados relacional ou manipularficheiros no servidor. As características mais importantes do JavaScript são:

• Imperativa e estruturada – suporta a sintaxe da programação estruturada C, o quefacilita a implementação;

• Dinâmica – Os tipos de objectos estão associados aos valores e não com as variáveis;

32


Figura 2.12: Validação de um formulário usando JavaScript

• Funcional – As funções são elas próprias objectos, e podem ser definidas para va-riáveis, passadas como argumento, e retornadas por outras funções.

O Cascading Style Sheets ou CSS é uma linguagem usada para a apresentação e for-matação de um documento HTML. O CSS permite a separação entre os conteúdos dosdocumentos, definidos por exemplo usando o HTML , e a apresentação deste. Actual-mente está a ser desenvolvida a versão 3 pela W3C, que começou a ser implementada emDezembro de 2005 [W3C11a]. Algumas das novas funcionalidades do CSS3:

• Suporte de novos módulos de cor como o HSL, CMYK, HSLA e RGBA;

• Bordas gradientes;

• Bordas com imagens;

• Caixas com cantos redondos;

• Caixas com sombreados;

• Múltiplas colunas de texto sem necessitar de tabelas;

• Textos com sombreados.

Tal como o HTML 5, o CSS é uma plataforma aberta que não necessita de qualquersoftware para se tirar partido, sendo somente necessário o browser. Em conjunto com astecnologias CSS e JavaScript, o HTML5 consegue disponibilizar recursos para desenvol-ver aplicações mais dinâmicas e ao mesmo tempo com melhor interactividade.

2.3.3 Análise Comparativa do Flash e HTML 5

As tecnologias web são hoje muito discutidas, em virtude do surgimento de novasplataformas a um ritmo alucinante. O Flash e o HTML 5, não fogem à regra, contribuindo

33


Figura 2.13: Exemplo do CSS3 usado para simular um ambiente MacOS

para tal a disputa entre a Adobe, proprietária do Flash e a Apple, aliada do HTML 5[App11].

O Flash é uma das tecnologias mais em voga devido à sua compatibilidade e flexi-bilidade com os sistemas web, apresentando contudo algumas limitações e falhas. Emseguida, pode-se verificar as vantagens da utilização do Flash:

• Facilidade de aprendizagem pois é uma tecnologia já muito consolidada no mer-cado;

• Massificação da tecnologia;

• Compatibilidade com várias plataformas e sistemas operativos;

• DRM facilitado para o conteúdo estar inacessível para cópia;

• Alto nível de interactividade;

• Aceleração por hardware.

Como se pode ver, o Flash apresenta grandes vantagens, no entanto não está livre dedefeitos:

• O desenvolvimento pode ter custos a nível monetário, devido à necessidade de pagarpelas ferramentas da Adobe como Flash Profissional;

• Incompatibilidade com os sistemas iOS que suportam os equipamentos móveis daApple como o iPad, iPod ou iPhone;

• A implementação do Flash quebra com os standards Web;

34


• O conteúdo Flash não é indexado pela maioria dos motores de busca, limitando opage rank dessas aplicações web;

• O tempo de espera do carregamento da aplicação Flash pode ser considerável;

• Necessidade de se usar o plug-in para o utilizador usufruir do Flash.

. O HTML 5 é a próxima versão do HTML que introduz novas e excitantes funciona-lidades, sendo no entanto uma plataforma ainda em desenvolvimento sem “lançamento”previsto. Algumas das vantagens apontadas ao HTML5, mesmo nesta fase embrionária,são:

• Aceleração por hardware, levando, em teoria, a uma melhor performance;

• Plataforma aberta, o que significa que não é necessário nenhum software em espe-cial, apenas o browser;

• Sem custos de desenvolvimento para o programador;

• O desenvolvimento actual apoiado por grandes empresas na área de Informáticacomo a Apple, Microsoft, Google, entre outros;

• Compatível em sistemas iOS;

• Novas funcionalidades até agora disponíveis somente através de aplicações third-party como é o caso do <vídeo>.

Uma das maiores desvantagens do HTML5 é o facto de estar ainda em desenvolvi-mento, o que implica mudanças e problemas de compatibilidade nos dias de hoje. Destaforma, os problemas apontados ao HTML5 são:

• Razoável compatibilidade com os browsers e plataformas actuais;

• Ainda em desenvolvimento e sujeito a mudanças;

• Ferramentas de desenvolvimento limitadas;

• Apesar de já ser suportado na versão Internet Explorer 9, o elemento <vídeo> nãoé suportado nas versões anteriores, o que cria uma barreira à adopção do elemento<vídeo>;

• O fim do desenvolvimento não está previsto para os próximos anos [WHA11b].

Com o surgimento do HTML 5 o Flash não irá desaparecer, sendo no entanto de enal-tecer o facto do Flash estar presente em grande escala na web. A utilização do HTML 5em dispositivos móveis é da maior utilidade, devido ao seu suporte por parte dos sistemasAndroid, iOS, Palm OS ou Blackberry. Actualmente, com o estado de desenvolvimento

35


do HTML5, este é mais adequado para ser usado em plataformas Apple como iPhone,iPods ou iPads, devido à restrição da tecnologia da Adobe nestes sistemas.

O Flash, sendo uma tecnologia criada na era dos computadores pessoais, é a plata-forma indicada para a criação da maioria das aplicações interactivas online. O seu grandetrunfo é ser compatível com muitos e variados browsers, o que estimula a interoperabili-dade. A possibilidade de DRM é outra das grande razões pela qual sites como Youtube ausam.

Como o trabalho incidirá sobre os tablets, e o iPad detém uma grande parte do mer-cado, o desenvolvimento terá de ser realizado em HTML 5 em conjunto com JavaScript eCSS3.

2.3.4 Frameworks Mobile HTML5

Com a proliferação dos dispositivos móveis, surgiram várias frameworks HTML5/CSS3com intuito de suportar o desenvolvimento de aplicações destinadas às plataformas mó-veis, com interfaces tácteis. Estas frameworks oferecem um maior e mais consistentesuporte do HTML5 e CSS3, além de mitigarem as diferências entre os vários sistemasoperativos móveis. Providenciam um conjunto de métodos e ferramentas que auxiliam,por exemplo a integração dos eventos multi toque ou a definição de um layout orientadoa dispositivos móveis. Foram analisadas e testadas algumas das frameworks disponíveisa fim de escolher a que melhor se adequa ao projecto. Assim, as frameworks que forampostas à prova são:

• Sencha Touch;

• JQTouch;

• JQuery Mobile.

O Sencha Touch [Lab11b] é uma framework bastante poderosa e rica em funcionali-dades quando comparada com as restantes. Suporta dispositivos baseados em Android eiOS, providenciando um conjunto alargado de eventos touch e animações. As aplicaçõesweb desenvolvidas via Sencha Touch são independentes da resolução, o que constitui umamais valia na utilização em multi-plataformas e dispositivos. Contudo, apesar de todas asfuncionalidades que o Sencha Touch oferece, a programação é efectuada usando a libraryde JavaScript ExtJS. O ExtJS tem, tipicamente, uma grande curva de aprendizagem o quealiado ao facto de os tutoriais disponíveis não oferecerem grande ajuda, faz com que oSencha Touch seja uma opção pouco viável.

O JQTouch é um plugin desenvolvido para a library popular JQuery [Lab11a]. Ofe-rece os eventos touch e gestures nativos da plataforma iOS, suportando iPhone e iPodTouch, sendo no entanto possível utilizar outros dispositivos móveis, sem garantia detotal compatibilidade. O plugin disponibiliza vários temas customizáveis consoante os

36


requisitos da aplicação. Os poucos dispositivos suportados, incluindo a falta de um su-porte aos tablets, a falta de documentação, com poucos exemplos disponíveis no site e amanutenção e desenvolvimento lento, ditaram o afastamento do JQTouch.

O JQuery Mobile é uma framework baseada, tal como o nome indica, no JQuery e édesenvolvida pela mesma equipa que desenvolve o JQuery [JM11]. No site contém a APIe várias demos, o que facilita o uso da framework. Apesar de estar ainda em fase Alpha4, já apresenta um vasto leque de funcionalidades, onde se destacam os seguintes:

• Compatibilidade com iOS, Android, BlackBerry, Symbian, Windows Phone, entreoutros;

• Optimizado para tablets e smartphones;

• Vários temas disponíveis e customizáveis;

• Facilidade de uso;

• Controlo de eventos baseados em touch;

O JQuery Mobile apresenta uma grande comunidade, além de ter um desenvolvimentosustentado e contínuo. A framework é actualmente suportada por empresas reconhecidascomo Mozilla Corporation, Blackberry ou Adobe, o que é mais um ponto que evidenciaa sua qualidade. Desta forma, a escolha recai sobre o JQuery Mobile, pois contém todosos elementos necessários para o projecto.

37

Capítulo 3

Especificação do Projecto

Os sistemas file-based vieram para ficar e prova disso é a constante evolução que setem verificado ao longo dos últimos anos, e a estagnação que tem afectado os sistemastape-based. As limitações dos sistemas baseados em tapes provocaram o advento dossistemas integrados baseados no formato MXF. Os workflows dos file-based são bastantediferentes dos actuais workflows dos sistemas tape-based.

Figura 3.1: Workflow de um sistema baseado em tapes [DWBT06]

Os workflows que se baseiam em tapes, Figura 3.5, têm processos próprios devidoàs características intrínsicas das tapes. O material é capturado, e depois é levado paraPós-Produção. Na Pós-Produção, são editados de forma linear os conteúdos. Antes doaparecimento de software de edição, a edição dos conteúdos era feita através da directamanipulação da tape, usando um VTR, com outra tape a servir como destino. O editornecessitava de avançar ou retroceder a tape, por não ser fisicamente possível aceder a uma

38


frame directamente. Depois da Pós-Produção, o material editado segue para distribuição.No fim da difusão, as tapes são armazenadas em arquivo, com as outras tapes.

Como pode ser visto a produção de material televisivo com tapes oferece várias fra-gilidades. As tapes, desde que são gravadas "viajam"por todo o processo. A edição élinear, o que traz muitas complicações e pouca flexidade à Pós-Produção quando com-parado com os sistemas actuais de edição não-lineares. O sistema de arquivo de tapes,tende a ser de difícil organização além de ocupar bastante espaço físico. Como as tapessó podem ser utilizadas algumas vezes para gravação, é necessário novas tapes ao fim dealgumas gravações de conteúdo audiovisual, o que acarreta custos elevados. Os proble-mas tinham que ser eliminados ou, na pior das hipóteses, minimizados pelo que foi umquestão de tempo e tecnologia até começarem a surgir sistemas digitais que integrassemtodas as fases associadas ao broadcasting.

Figura 3.2: Workflow de um sistema baseado em ficheiros [DWBT06]

O fluxo de trabalho dos sistemas centralizados em ficheiros, Figura 3.2, permitem ex-plorar novas possibilidades, como streaming via Web ou através de dispositivos móveis.Além da abertura da Televisão a novos devices e plataformas, os sistemas de ficheirostrazem optimizações aos workflows de produção de vídeo profissional e consequente-mente redução de custos. O workflow dos sistemas file-based, descrito na secção 2.1.1,diferencia-se em todas as fases do workflow dos, agora obsoletos, tape-based systems.

Na fase de captura são usados discos ópticos, como são exemplo os discos da SonyXDCam, ou SSDs como é o caso do modelo P2 da Panasonic. Estes devices permitemfácil acesso ao conteúdo, alto índice de reusabilidade, baixo custo, velocidades altas dedatarate, e claro a possibilidade de fazer NLE através de um software de edição profissi-onal. O material depois de ter sido gravado, é lido por um VTR ou um leitor dos discosópticos ou SSD para ser feito ingest através duma interface HD-SDI/SDI, USB, firewireou pelo protocolo FTP. O resultado da operação de ingest são ficheiros passíveis de serem

39


editados.A fase de Pós-Produção dedica-se à alteração e edição dos conteúdos anteriormente

gravados. O surgimento de software de edição cada vez mais poderoso, permitiu que aEdição fosse ganhando maior protagonismo. A adição de efeitos especiais visuais atravésda tecnologia CGI, permitiu um grande avanço na alteração dos conteúdos previamentecapturados.

A distribuição dos conteúdos é hoje feita em sinal HD, para plataformas Web e mobile.A Televisão é actualmente difundida para mais dispositivos, e teve que entrar na Internetsob pena de ser substituída e perder audências para outros meios de comunicação. A Tele-visão através de dispositivos móveis está a ganhar cada vez mais adeptos, sendo exemploo aumento de mais de 500% de dispositivos móveis que visualizaram as Olimpíadas deVancouver 2010, comparativamente às Olímpiadas de Beijing 2008 [Rev].

O arquivo engloba os processos de armazenamento e registo dos conteúdos. Depoisdo material ser difundido, este é guardado em storages servers.

A Televisão enfrenta grandes desafios, não sendo tão importante e única como o eranas décadas anteriores. Um canal de televisão enfrenta a concorrência de websites, deblogs, do Youtube, de outros canais de televisão, além dos tradicionais concorrentes comoa Rádio. A optimização de processos, nos tempos que correm, torna-se assim mais impor-tante do que nunca para a Televisão. A produção de notícias televisivas é um caso ondeesta optimização é ainda mais essencial, por ser, muitas das vezes, onde as televisõesobtêm as maiores audiências.

As notícias são eventos relevantes para a sociedade, que são necessários difundir emvirtude do objectivo principal dos meios de comunicação: transmitir informação. Comonem sempre é possível prever a ocorrência de um evento passível de ser notícia, as reda-ções têm de estar preparadas para todo o tipo de notícias. A informação que é difundida,passa por um longo processo até chegar às audiências. O workflow de produção das notí-cias pela Televisão, foco da tese proposta, é detalhado no próximo capítulo.

3.1 Produção de Notícias

Da realização das Teses de Mestrado de Francisco Brito [Bri11] e José Nuno Fer-reira [Fer11] propostas pela MOG, foram realizadas duas visitas aos estúdios da televisãoestatal portuguesa RTP. O objectivo principal das visitas foi o de perceber e analisar o pro-cesso de produção de notícias de um canal de televisão. Embora seja descrito o processode produção de notícias da RTP, pode-se considerar que este processo é muito semelhanteao de qualquer outro canal de televisão.

A RTP é o canal de televisão estatal de Portugal, e dedica-se à produção de variadosconteúdos televisivos como telejornais, concursos ou transmissão de eventos desportivos.

40


A RTP tem a seu cargo dois gabinetes localizados no Porto e em Lisboa. De seguida, iráser detalhado o processo de produção de notícias usado no canal de televisão referido.

3.1.1 Workflow actual

O workflow da RTP relativamente à produção de notícias consiste em cinco fases[Fer11]:

• Aquisição do tema da notícia;

• Angariação de informação;

• Edição;

• Publicação;

• Broadcasting.

Na fase de aquisição do tema da notícia, o jornalista descobre um evento passívelde ser noticiado ou é-lhe atribuído pelo redactor um tema para posterior divulgação. Aequipa de produção de notícias tem acesso a um conjunto alargado de fontes de informa-ção como: agências de notícias, meios de comunicação impressos, tais como jornais ourevistas, Rádio, contribuições de telespectadores, websites, entre outros. Se a notícia forda iniciativa do jornalista, esta está dependente do aprovação do Director de Informação.

A fase seguinte, é a fase onde o jornalista procede ao desenvolvimento da notícia . Ojornalista, caso tenha essa possibilidade, desloca-se ao local onde ocorreu o evento paraum melhor apuramento dos factos, por exemplo através de entrevistas ou de gravaçõesvídeo. No entanto, o jornalista apoia-se sempre em outros meios de comunicação parauma definição mais precisa e correcta do conteúdo. As agências de notícias são um fortealiado nesta fase, pois possibilitam o acesso a um vasto leque de notícias em tempo real.Depois de feita a filtragem e selecção do conteúdo a ser produzido, o jornalista procede àfase de edição.

Depois de criado o tema e respectivo conteúdo, o jornalista foca-se na edição da notí-cia. A notícia é editada, cortada e arranjada de forma a ser apelativa aos telespectadores.São adicionadas legendas, um técnica muito importante das notícias televisivas, pois aju-dam a manter o interesse do público. Depois de estar formatada e devidamente preparada,a notícia é armazenada em rede para ser publicada em servidores playout.

A publicação é a fase onde se realiza a adição da metadata definida pela RTP. Depoisda fase de pós-produção, é importante definir a metadata de forma concordante com ospadrões seguidos pelo canal de televisão. No caso da RTP, a metadata introduzida contéminformação relevante como: o texto de introdução que o apresentador do noticiário deveráler, ou informação essencial para a equipa de produção.

41


A última fase do workflow é a aquela onde as notícias, depois de estarem finalizadas,são difundidas para serem visualizadas pela audiência. As notícias produzidas estão nosservidores playout, e são adicionadas à timeline do software ENPS para serem transmiti-das.

A RTP tem ao seu dispôr várias ferramentas que auxiliam o processo de produção denotícias. O ENPS é um sistema de produção de notícias desenvolvido pela AP [ENP11].Integra editores de vídeo, armazenamento, e sistemas de outgest, permitindo aos jornalis-tas gerirem melhor as notícias a serem produzidas. O sistema é a base de todo o workflowassociado à produção de notícias na RTP. O sQ Edit é um software NLE desenvolvidopela Quantel, que providencia funcionalidades para corrigir erros de imagens como cor, eainda multi-camadas de composição ou masking faces.

Como foi referido anteriormente, o jornalista pode precisar de aceder aos serviços fa-cultados pelas agências de notícias. Caso a RTP não consiga cobrir uma notícia, recorreaos baskets que as agências fornecem para assim poder divulgar a notícia. Notícias in-ternacionais são muitas vezes divulgadas, tendo por base agências como a Reuters ou aAP, pois é impraticável para canais de televisão de semelhantes à RTP terem colaborado-res espalhados pelo Mundo inteiro. Quando um jornalista procura informação sobre umadada notícia nos serviços das agências, o processo que segue é, tipicamente, o seguinte:

1. Acede ao website da agência de noticias;

2. Procura pelos assets que deseja exclusivamente pelo nome do asset;

3. Para cada asset, o jornalista tira uma nota da referência do mesmo;

4. Repete os primeiros três passos para as todas as agências que dispõe;

5. O jornalista procura os assets, no editor de vídeo, usando as referências retiradas nopasso 3, para proceder à edição;

6. No final, o asset é guardado num servidor playout, para ser posteriormente adicio-nado ao bloco de notícias pelo software ENPS, em conjunto com a metadata.

Analisando o processo, é possível perceber que este é relativamente eficiente. Nocaso da RTP, como tem acesso a várias agências, este processo pode tornar-se moroso epropício a erros. Contudo pode ser optimizado, em virtude da necessidade de aceder aosvários baskets separadamente, ou da pesquisa pelo asset poder apenas ser feita pelo nomede ficheiro. A procura do asset é feita de forma separada relativamente à pesquisa darespectiva metadata, o que também pode originar falhas. Uma proposta de solução quevisa corrigir os problemas e melhorar o workflow dos jornalistas é proposto na próximasecção.

42


3.2 newsRail

A solução proposta é um sistema centralizado como único ponto de acesso aos assetsdos vários baskets, com pesquisa avançada de assets e respectiva metadata e possibilidadede exportação para o editor de vídeo. Providencia um melhor paradigma de pesquisaorientada não só por palavras-chave, mas também por duração, basket de origem, ou peloestado de exportação dos assets, isto é, exportado ou não exportado. É possível organizar"vistas"com critérios de pesquisa diferenciados, para uma melhor organização da vastainformação disponível. Relativamente ao workflow dos jornalistas da RTP, o newsRailpermite optimizá-lo na medida em que:

• Evita a repetição dos três primeiros passos do workflow original;

• A probabilidade de ocorrerem erros provenientes de uma pesquisa errónea é inferior;

• O vídeo fica automaticamente disponível no editor de vídeo.

3.2.1 Requisitos

3.2.1.1 Requisitos Funcionais

O newsRail foi definido segundo um conjunto de requisitos functionais e não-funcionais,essenciais para uma melhor compreensão e implementação do sistema. Depois da análiseefectuada ao workflow da RTP e dos problemas inerentes ao mesmo, foram descritos osseguintes requisitos funcionais:

• Geração automática das versões proxy de cada basket configurado;

• Pesquisa, filtragem, ordenação e pré-visualização dos vídeos e respectiva metadata;

• Exportar os vídeos directamente para o ambiente de edição.

A primeira funcionalidade diz respeito à descoberta automática, por parte do news-Rail, de novos assets em algum dos baskets e respectivo ingest. Os vídeos que as agên-cias de notícias disponibilizam nos baskets estão em formato HD, pelo que é necessárioefectuar o transcode dos vídeos para formatos de mais baixa resolução e de dimensões in-feriores, chamados de proxy. Estes vídeos proxy, são mais apropriados à pre-visualizaçãoe à edição. Além da geração dos proxys, o newsRail também deve gerar keyframes, quenão são mais que imagens do vídeo original. Como o newsRail está orientado a tablets,beneficiam de vídeos de dimensões reduzidas pois estes dispositivos possuem velocida-des de transmissão de dados inferiores aos computadores desktop. Os vídeos proxy e arespectiva keyframe serão usados pela UI para efectuar as operações de pesquisa ou defiltragem.

43


O segundo requisito é o conjunto de operações que o utilizador poderá efectuar parauma melhor e mais precisa selecção dos vídeos a serem exportados. Para escolher os ví-deos, o sistema providencia um leque de filtros onde se inclui a data máxima e/ou mínimado asset, duração mínima e/ou máxima do asset, entre outros que serão discutidos empormenor no próximo capítulo. A listagem dos assets, além de poderem ser filtrados deacordo com um conjunto de restrições, podem também ser ordenados por critérios comoduração ascendente ou descendente. Para uma melhor visualização da metadata e do pró-prio vídeo, o sistema deve ter um modo preview. Este modo possibilita ao utilizador, vero proxy em dimensões maiores com um grande ênfase na metadata associada. A pesquisapor palavras-chave, como em todos os sistemas de selecção e pesquisa, deve também serpossível de efectuar, não só pelo nome do ficheiro, mas também pelos campos de textopresentes na metadata.

O último requisito funcional solicita que o newsRail possa, através da acção do utili-zador, exportar os vídeos seleccionados para o software de edição de vídeo. O passo finaldo workflow do newsRail é dar a possibilidade de exportar os vídeos para o editor de ví-deo, para depois proceder à pós-produção das notícias. Este requisito é fundamental, poissem ele o newsRail falha na conclusão do seu objectivo principal: melhorar o workflowdos jornalistas e ser transparente desde os serviços das agências de notícias até ao editorde vídeo.

3.2.1.2 Requisitos não-funcionais

Os requisitos não-funcionais, especificam os critérios que avaliam o sistema como umtodo e não pelas suas funcionalidades. Por ser um sistema distribuído e acedido via web,são necessários determinados requisitos não-funcionais que são detalhados em seguida:

• Portabilidade - Devido ao aumento dos tablets e seus sistemas operativos, é esperadoque o sistema tenha a capacidade de se adaptar facilmente a novos ambientes. Astecnologias front-end usadas no projecto e a cada vez maior adopção das mesmas éum prenúncio quanto à portabilidade do sistema.

• Usabilidade - Sendo o projecto orientado aos dispositivos tablets é importante quea UI esteja de acordo com as limitações e potencialidades inerentes a estes tipos dedispositivos. Deve providenciar uma UI simples, intuitiva e também adequada aosambientes do jornalismo.

• Flexibilidade - O sistema deve permitir a adição de novas funcionalidades, de formaa poder evoluir confortavelmente segundo necessidades que forem surgindo. Comoo newsRail foi desenhado tendo por base o workflow da RTP, este requisito torna-sevital dado a existência de vários workflows diferentes de produção de notícias.

44


• Interoperabilidade - Como existem várias agências de notícias diferenntes, que pro-videnciam os assets com características próprias como o formato de vídeo usadoou o tipo descrição da metadata, é desejável que o sistema tenha a abilidade de seadaptar aos diferentes requisitos impostos.

• Desempenho - O desempenho é fundamental em qualquer software, e no caso espe-cífico de sistemas de apoio à produção de notícias, este requisito ganha ainda maisimportância. O newsRail visa optimizar e melhorar o workflow de produção de notí-cias, pelo que é necessário e óbvio que o sistema tenha um tempo de resposta baixosob pena de perder as vantagens que traz aos jornalistas.

3.2.2 Workflow do newsRail

Antes de detalhar a arquitectura utilizada pelo newsRail, é necessário proceder à ex-plicação de todo o workflow do newsRail.

Figura 3.3: Workflow do newsRail

A representação do workflow do newsRail, Figura 3.3, contempla o sistema tal comofoi idealizado. O estado actual do middleware não possibilita, por exemplo, utilizadoresdiferenciados, ou seja, só permite um administrador que tem acesso a todas as funciona-lidades que o sistema oferece. Os utilizadores acedem ao newsRail através do protocoloHTTP, usando um web browser. O newsRail está à "escuta"nos baskets configurados equando um novo asset é adicionado a um basket é feito o seu processamento. O proces-samento inclui transcodificar o vídeo do asset para uma versão proxy e popular a basede dados com a informação do vídeo e respectiva metadata. O Rhozet Carbon Coder é osoftware de transcodificação usado na geração das versões proxy, para a UI, e das versõesHD para o editor de vídeo. Para um melhor esclarecimento de todo o fluxo de trabalho,são de seguida detalhados os passos necessários:

45


1. Depois de devidamente configurados os baskets, o newsRail monotoriza cada basketà espera de novos assets;

2. Quando surge um novo asset, o newsRail, caso este ainda não esteja na presente nabase de dados, analisa a metadata e regista a informação na base de dados e ordenaao Carbon Coder para efectuar o transcode do vídeo para a versão proxy. Além dovídeo, o Carbon Coder gera também a keyframe que como imagem de preview dovídeo;

3. Caso o utilizador actualize a UI, o novo vídeo do asset será mostrado na lista deassets, bem como a metadata e o keyframe;

4. O utilizador requisita uma operação de exportação de, pelo menos, um asset e onewsRail envia um pedido ao Carbon Coder para a geração da versao HD do asset,para um sistema de ingest de ficheiros como o mxfSPEEDRAIL F1000.

Na secção seguinte serão especificadas, em pormenor, as infraestruturas que suportamtodo o funcionamento do newsRail, como é que se relacionam entre si e quais as suaspropriedades e restrições.

3.2.3 Arquitectura

A arquitectura do newsRail pode ser definida como sendo uma arquitectura de trêscamadas. A arquitectura de três camadas é muito comum em aplicações orientadas à web,e define que a camada de apresentação, está separada da camada da lógica de negócios eda camada de mais baixo nível, onde são armazenados os dados [Eck95]. A camada demais alto nível, a de apresentação, é a única camada com a qual o utilizador interage. Estacamada, âmbito da tese proposta, foi realizada com o auxílio das tecnologias HTML5,CSS3 e JavaScript, como já fora anteriormente referido. Dos detalhes da sua implementa-ção serão abordados no capítulo seguinte. A camada intermédia, ou middleware, é aquelaque interliga a camada superior de apresentação e a base de dados.

O componente central do middleware é o Bobsled. O Bobsled é uma framework de-senvolvida pela MOG para suporte das suas soluções. A framework providencia um con-junto de ferramentas e conceitos, nomeadamente Rules, Flows e Operations que permite odesenvolvimento de diferentes workflows. As Rules são regras de monitorização dos bas-kets, isto é, cada basket tem a sua própria Rule que é guardada em base de dados e estacontém informação como localização do basket ou do Carbon Coder. Os Flows registam ainformação sobre os assets que vão ser transcodificados para versões HD, localização doCarbon Coder e o destino do transcode. As Flows, ao contrário das Rules, só existem noperíodo do trabalho a ser efectuado pelo Carbon Coder, pelo que é necessário criar Flows

46


Figura 3.4: Arquitectura do newsRail

sempre que o utilizador submete assets para exportar. As Operations, que estão imple-mentadas para o Carbon Coder, através da extensão CarbonCoderOperation, servem paraconectar e monitorizar o Carbon Coder, durante o transcode das versões proxy e HD.

O Bobsled disponibiliza os web services, pelos quais a camada superior comunica.Contudo, o Bobsled não cobria todas as necessidades do newsRail, pelo que teve de sermodificado para fornecer todas as funcionalidades requiridas. Os conceitos de asset oubasket eram desconhecidos pelo Bobsled, pelo que tiveram de ser criados novos módulos.Foram implementados e adicionados ao Bobsled um conjunto de módulos, nomeadamenteo newsRailCommon, CarbonCoderOperation e ReutersExtension.

O newsRailCommon é responsável pela implementação dos componentes nuclearesdo newsRail. Providencia as funcionalidades específicas ao contexto do newsRail, bemcomo os web services relacionados com a gestão dos assets e baskets.

O CarbonCoderOperation é o módulo responsável pela comunicação e gestão com osoftware de transcode Carbon Coder. O CarbonCoderOperation submete um conjunto detrabalhos ao Carbon Coder, nomeadamente geração de:

• Keyframe de cada asset;

• Versão proxy de cada asset;

47


• Versão HD para o editor de vídeo.

O Carbon Coder é um software de transcode de ficheiros que suporta multi formatos.O protocolo de comunicação entre o Carbon Coder e o componente newsRailCommoné sockets. O uso de sockets permite a comunicação bi-direccional entre o receptor e oemissor. No caso particular do newsRail, o Carbon Coder depois de receber um trabalhoa efectuar, vai enviando o feedback do resultado, como por exemplo a percentagem deconclusão.

O ReutersExtension é o componente que processa o basket da agência Reuters. Cadaagência de notícias disponibiliza os assets de forma diferenciada, logo é necessário queo newsRail analise e trate a informação individualmente. A Reuters disponibiliza a me-tadata de forma diferenciada de outras agências de notícias como a EBU, pelo que énecessário que o parser seja exclusivo a um basket. Comparando ainda a Reuters coma EBU, os vídeos da primeira já vêm dos baskets separados, isto é, cada vídeo corres-ponde a uma notícia diferente, algo que na EBU não acontece, pois esta disponibilizaperiodicamente um vídeo contendo as várias notícias.

Como SGBD foi escolhido o software MongoDB [10g11] por já ser a base de da-dos usada na framework do Bobsled. A base de dados regista informação sobre assets,baskets, coders e também as localizações dos proxies e das versões HD para edição. OMongoDB apresenta várias vantagens relativamente às tradicionais base de dados, nome-adamente:

• É um projecto open-source com uma grande e activa comunidade;

• Suporta replicação automática de dados entre servidores em caso de ocorrência deerros críticos ou redundância;

• Como é uma base de dados do tipo NoSQL, não usa um estrito esquema de dados,o que permite actualizações de software mais fáceis, e consequentemente maiorescalabilidade;

• É free.

3.2.3.1 Web Services

O newsRail disponibiliza os dois tipos de interfaces web services mais comuns entre ocliente e o middleware, as interfaces REST e SOAP. Existem duas familías de interfacesno sistema newsRail, as interfaces do Bobsled Core e as interfaces do newsRailCommon.Como foi referido anteriormente, o newsRailCommon disponibiliza web services especí-ficas ao contexto do sistema. Este módulo implementa os seguintes web services:

• IAssetManagement - responsável pela gestão dos assets do newsRail. Regista mé-todos de listagem/pesquisa e remoção dos assets;

48


• IBasketManagement - responsável pelo CRUD dos baskets do newsRail;

• INRailSystemSettingsManagement - responsável pelas configurações do newsRail.

Figura 3.5: Pedidos SOAP e REST do método de login

O Bobsled Core oferece as interfaces que são usadas nos produtos da MOG, e que per-mitem escalar tipicamente as necessidades dos utilizadores desses produtos. As interfacesque o módulo referido implementa são:

• IRuleManagement - oferece um conjunto de métodos para efectuar o CRUD dasRules;

• ISessionManagement - tal como o nome indica, oferece os métodos de autenticaçãodo sistema;

• IFlowManagement - disponibiliza os métodos de gestão dos Flows;

• INotificationManagement - contém os métodos que gerem as notificações do Bobs-led. Estas notificações incluem, por exemplo, o estado do trabalho de exportação deum dado asset, ou a sua percentagem de conclusão;

• IEventHubWS - contém o método que retorna os endpoints das interfaces;

• IStorageManagement - gere os storages das Rules e dos Flows. Os storages são osarmazenamentos onde são guardados as versões proxy e as versões HD;

• ISystemSettingsManagement - como pode ser facilmente inferido, esta interfacecontém os métodos que ajudam a configurar o newsRail;

• ILicensingManagement - disponibiliza os métodos para verificar o licenciamento doproduto.

49


Os web services implementados pelo Bobsled e pelo newsRailCommon permitem aocliente ligar-se em qualquer ponto da rede, o que aumenta a interoperabilidade do news-Rail. A disponibilização de um conjunto alargado de métodos faz com que a camadade apresentação se mantenha agnóstico em relação às operações do newsRail. A utiliza-ção dos Web Services permite que o sistema seja bastante flexível, além de ajudar à tãodesejada interoperabilidade do newsRail.

3.2.4 Mockups

O Projecto proposto consiste no desenvolvimento de uma UI orientada aos tablets parao sistema newsRail. Para uma melhor definição do paradigma de interacção e contextodo sistema, foram definidos um conjunto de mockups para serem depois analisados eescrutinados na sessão de Avaliação Heurística levado a cabo na MOG Solutions.

O newsRail é um sistema diferenciado dos outros existentes na MOG Solutions, peloque nem todas as metáforas de interacção podem ser usadas no newsRail. O desenvol-vimento vocacionado para os tablets, também contribui para este facto. Desta forma, aimplementação dos mockups foi desafiante e ao mesmo tempo motivadora.

Os mockups foram definidos através do software Evolus Pencil [Pro11]. O EvolusPencil é um software open-source para realização de protótipos de baixo-nível. Pode serusado como um addon do browser Firefox ou como uma aplicação standalone. Ofereceum grande conjunto de elementos e formas para uma definição clara da interface, comoforms, barras de progresso ou tabs, só para citar alguns. Uma das grandes vantagens doEvolus é a possibilidade de interligar as várias páginas, e exportá-las para um HTML.Desta forma, é possível uma definição de todo o sistema.

Como pode ser visto na secção 2.1.3, os produtos da MOG apresentam uma interfaceescura. Como a maioria dos softwares de produção de conteúdo audiovisual é usado emsalas escuras, é comum estes terem um layout de cores escuras para minimizar o cansaçodos olhos. Apesar do newsRail oferecer uma mobilidade que permite o seu uso fora dassalas e estúdios de Televisão, o software ENPS e o sQ Edit, presente no workflow deprodução de notícias, apresentam padrões escuros, pelo que é lógico os mockups seremdefinidos com cores escuras.

Outra das metáforas seguidas foi o uso de uma barra de controlo. Tal onde acontecenos produtos da MOG, os mockups foram desenhados tendo em conta uma barra superiorde controlo. Esta barra possui as funcionalidades de gestão e controlo da aplicação e quesão menos usadas como o logout ou as definições do sistema.

Como se trata dum protótipo de baixa fidelidade, mas horizontal no âmbito, os moc-kups que foram definidos contêm todas as funcionalidades requiridas, entre as quais sedestacam o login, listagem dos assets, pré-visualização de um asset e exportação de as-sets.

50


Um dos aspectos que se teve em conta durante a realização dos mockups, além dasmetáforas anteriormente referidas, foi o design orientado a tablets. Por ser uma tecnologiarecente, ainda existem problemas de usabilidade em aplicações e websites desenhadospara tablets [BN11]. Os mockups foram portanto já devidamente especificados tendo emconta estes problemas.

3.2.5 Avaliação Heurística

A Avaliação Heurística é um método de inspecção de usabilidade dedicado a avaliarsoftware, que foi introduzido pelo consultor de Usabilidade Jakob Nielsen [It11]. Se-gundo Nielsen, esta tipo de inspecção tem dois grandes objectivos:

• Identificar problemas e falhas da usabilidade da interface;

• Identificar aspectos positivos da usabilidade da interface.

Este método descreve que são necessários cinco experts em Usabilidade, e reconheceque o conhecimento do contexto do software a ser analisado é uma mais-valia. Comotal, a inspecção foi efectuada na MOG Solutions, por cinco dos seus colaboradores. Oscinco colaboradores escolhidos já tinham tido uma formação em Usabilidade realizadana própria empresa. Por forma a realizar uma melhor Avaliação Heurística, os expertsque realizaram a inspecção apresentam diferentes funções e responsabilidades dentro daMOG. Os avaliadores pertenciam aos seguintes departamentos:

• Business Development;

• Software Development;

• Project Management;

• Marketing.

A primeira parte da avaliação consistiu numa descrição do newsRail, objectivos daAvaliação Heurística e plano de actividades da mesma. Foi distribuído um conjunto dedocumentos que auxiliou o processo, nomeadamente a lista das heurísticas de Nielsen, osseverity codes da Usabilidade, o guião a ser usado durante Avaliação Heurística e umafolha de cálculo para cada avaliador enumerar e descrever os problemas encontrados.

A segunda parte da avaliação teve como foco a análise da interface. Cada avaliadoresteve sozinho a seguir o guião, identificando ao longo do caminho possíveis falhas eproblemas relativamente à usabilidade do newsRail. A sessão teve a duração de sensivel-mente uma hora. Apesar de desejável, não foi possível testar os mockups em ambientestácteis. No entanto, foi transmitido aos experts que deveriam ter isso em consideração.

A terceira e última parte da sessão, consistiu na análise dos resultados em grupo.Foram revistos os problemas apontados por cada avaliador e discutidas possiveis soluções.

51


O resultado final da reunião foi bastante proveitoso para o projecto, pois permitiu ao autorperceber as falhas e os aspectos positivos da usabilidade dos mockups. A reunião teve aduração de aproximadamente duas horas.

3.2.5.1 Resultados

Tabela 3.1: Tabela com os problemas de usabilidade identificados

N.o Descrição do problema Módulo1 Opção de "Settings" Autenticação2 Adicionar keyframe nos vídeos Listagem dos vídeos3 Opção de "Export"no topo à direita Listagem dos vídeos4 Checkbox de "Export"para cada asset Listagem dos vídeos5 Ao seleccionar a opção "Export"deve ser apresentado

um menu para escolha dos destinos Listagem dos vídeos6 Deve existir a opção "Last Export"para facilitar a

exportação de assets para o último destino Listagem dos vídeos7 Opções "Select All"e "Clear All" Listagem dos vídeos,

Exportação dos vídeos8 Vistas para filtros, pesquisas e ordenações customizadas Listagem dos vídeos,

Exportação dos vídeos9 "Logout"e "Settings"devem estar no canto superior direito do ecrã Listagem dos vídeos,

Exportação dos vídeos10 Vista permanente e default de todos os assets Listagem dos vídeos,

Exportação dos vídeos11 Os filtros, ordenação e pesquisa, deve estar no lado esquerdo Listagem dos vídeos,

Exportação dos vídeos12 A pesquisa por palavras-chave deve estar correctamente assinalada Listagem dos vídeos,

Exportação dos vídeos13 O vídeo a ser visualizado e a respectiva metadata,

devem estar orientados horizontalmente Pré-visualização dos vídeos14 Falta da duração e basket do video a ser visualizado Pré-visualização dos vídeos15 No máximo devem aparecer 6 vídeos relacionados Pré-visualização dos vídeos16 A visualização dos assets em exportação deve ser

em lista com os elementos dispostos na horizontal Exportação dos vídeos17 As barras de progresso devem ter cores diferenciadas

para cada estado de exportação Exportação dos vídeos18 Os estados de exportação devem ser:

"Running", "Completed", "Failed"e "Canceled" Exportação dos vídeos19 Deve ser permitido cancelar um asset em exportação Exportação dos vídeos

Os problemas identificados variam quanto ao contexto a que se aplicam, como sepode verificar na Tabela 3.1, pelo que a Avaliação Heurística permitiu obter uma visãoalargada das falhas de interacção do protótipo. A Avaliação Heurística possibilitou efec-tuar as alterações devidas à UI e, consequentemente, ao paradigma de interacção. O

52


conhecimento dos avaliadores aliada à experiência na àrea de produção de conteúdos au-diovisuais, verificou-se essencial para a descoberta dos erros. Como pode ser visto nocapítulo seguinte, todas as falhas foram tidas em conta na implementação do protótipofuncional. As soluções encontradas para os problemas diferenciavam-se consoante o ava-liador, tendo-se contudo conseguido chegar a um consenso em quase todos os erros.

53

Capítulo 4

Implementação do Projecto

4.1 Abordagem

A metodologia de desenvolvimento de software utilizada foi o modelo em Espiral. Omodelo em Espiral é iterativo e é baseado na prototipagem evolutiva [Boe88]. O modelodefine quatro passos que devem ser seguidos em cada iteracção:

1. Determinar os objectivos e restrições da iteração;

2. Avaliar as alternativas e identificar os riscos associados a cada uma delas;

3. Desenvolver, validar e verificar o trabalho realizado;

4. Planear a próxima iteracção.

A implementação do Projecto foi executada em duas grandes iterações. A primeiraconsistiu na definição de um protótipo de baixa fidelidade, que culminou na realização deuma Avaliação Heurística. O protótipo consistiu num conjunto de mockups desenhadospara uma melhor concepção do projecto a implementar. Este protótipo, analisado nasecção 3.2.4, é horizontal ao sistema, pelo que aborda todo o workflow do newsRail.Aplicando os passos definidos pelo modelo em Espiral, é possível aplicá-los ao contextodesta iteração:

1. Identificar e avaliar os requisitos e restrições do newsRail

2. Escolher o software de prototipagem;

3. Desenvolver o protótipo e analisá-lo através de uma Avaliação Heurística;

4. Avaliar as mudanças necessárias e implementar as recomendações efectuadas naiteração seguinte.

A segunda iteração compreendeu toda a implementação do Projecto. Esta iteração iráser pormenorizadamente detalhada nas secções seguintes.

54


4.2 Desenvolvimento

A segunda iteração teve início após a realização da Avaliação Heurística. Esta iteraçãoteve os seguintes passos:

1. Determinar os objectivos e restrições do protótipo funcional;

2. Examinar e perceber o middleware e as ferramentas necessárias ao desenvolvi-mento;

3. Desenvolver e testar o protótipo;

4. Analisar o trabalho futuro do protótipo.

Como foi visto na secção 3.2.5.1, os resultados da Avaliação Heurística permitiramum novo e melhorado design da interface do newsRail. Os mockups foram alterados eserviram de base para a implementação do protótipo funcional. Este deveria endereçaros requisitos definidos na secção 3.2.1, bem como todas restrições definidas. Além dashabituais restrições inerentes à tecnologia e ao tempo de desenvolvimento, as restriçõesao nível da implementação do middleware do newsRail, também foram tidas em conta.Estas limitações foram aprofundadas no segundo passo.

Antes de proceder ao desenvolvimento do protótipo, foi necessário escolher as fer-ramentas de implementação. O IDE escolhido foi o Aptana Studio,pois é open-sourcee é dedicado à construção de aplicações Web. Além de incluir suporte para as tecnolo-gias Web a serem usadas no projecto como HMTL5, CSS3 e JavaScript, o Aptana Studiocontém as libraries de JavaScript mais usadas como Dojo, Prototype ou jQuery, base daframework JQuery Mobile utilizada no projecto. Oferece assistência de código, debug-ging, informação sobre o suporte dos browsers para cada método/função, e um servidorweb e HTTP built-in para pré-visualização do projecto.

O protótipo funcional foi implementado através da framework JQuery Mobile, alémdas tecnologias supracitadas. O JQuery Mobile possibilita a criação de aplicações weborientadas aos dispositivos móveis, com vários componentes à escolha. Um página defi-nida com o JQuery Mobile é constituída por três componentes: header, content e footer.O header, barra de navegação situada no topo da página, pode conter butões e/ou texto.No caso do newsRail, o header é sempre preenchido com dois butões, Settings e Logout,além da identificação actual da página e link para a página complementar. O content, talcomo o nome indica, é onde se localiza o conteúdo da página. O footer assemelha-se aoheader, localizando-se no fundo da página. Contudo, no newsRail o footer é meramenteindicativo do nome da aplicação. A framework oferece widgets que ajudam a formatar ainformação, como listas, formulários, colunas ou barras de navegação.

Para implementar o protótipo foi necessário realizar um estudo aprofundado do mid-dleware. Este estudo foi de grande utilidade, pois permitiu ao autor perceber melhor

55


como iria ser implementado a camada de apresentação do newsRail. Como foi referidona secção 3.2.3.1, o middleware oferece duas interfaces para os seus web services. Emvirtude da correcta implementação do projecto orientado a dispositivos do tipo tablet, fo-ram analisadas as vantagens e desvantagens do SOAP e REST. O SOAP é um protocolobastante rígido quando à sua definição, oferece melhores ferramentas de suporte, é versátilo suficiente para permitir a comunicação não só via HTTP, mas também via Java Mes-sage Service ou SMTP. O REST é mais leve e, consequentemente, gasta menos largura debanda comparado ao SOAP, é mais fácil de implementar e de aprender mas só pode serusado através do protocolo HTTP. A escolha recaiu sobre o REST por duas razões:

• É mais leve que SOAP, e dado que os tablets não beneficiam de ligações tão rápidascomo os tradicionais desktops e a aplicação carrega vídeos, este é um factor crítico;

• Menor complexidade na análise das mensagens através de JavaScript, comparativa-mente com o SOAP.

4.2.1 Autenticação e listagem dos vídeos

O presente módulo é a base de todo o workflow do newsRail e é responsável pelaautenticação e listagem dos vídeos. O middleware é gere a operação de ingest dos novosassets presentes nos baskets. Os baskets são pastas partilhadas que contêm assets de umadeterminada agência de notícias. Um asset é constituído por um vídeo de alta resolução,mais um ficheiro XML que contém a metadata. Os vídeos, nos casos da EBU e Reuters,estão no formato MPEG2, e são transcodificados para H.264/MPEG-4, através do CarbonCoder. A escolha do H.264/MPEG-4 prende-se com a compatibilidade oferecida pelosbrowsers, relativamente aos formatos VP8/WebM e Theora/Ogg. Actualmente, é o únicoque é suportado pelos browsers dos sistemas operativos iOS e Android. Antes de listar osvídeos, o newsRail precisa de se assegurar que o utilizador tem acesso ao sistema.

O utilizador autentica-se com a tradicional combinação de username e palavra-passe.A UI envia um pedido REST através de HTTP com o username e palavra-passe. O mid-dleware, caso valide o par recebido, responde com um sessionId. O sessionId é um GUIDque é representado por uma string hexadecimal de 32 caractéres [MSD11]. Para todosos pedidos REST, é necessário enviar o sessionId, excepto, como é óbvio, no pedido deautenticação de sistema.

Depois de autenticado, a UI envia dois pedidos REST da lista dos baskets e dos assets.O middleware responde a cada pedido, com a informação devida. O pedido da lista bas-kets é efectuado para saber quantos baskets estão configurados, para ser possível à UI criaros butões para cada basket. Um basket tem associado um conjunto de informações comonome, localização ou id. O pedido dos assets é complexo, pois envolve vários parâmetros,Figura 4.1. De seguida irá ser explicado o significado de cada parâmetro:

56


• assetsPerPage - define o número de assets que devem enviados na resposta;

• basketIds - ids dos baskets que devem ser procurados os assets

• keyword - string usada para pesquisar os assets;

• assetStatus - valor inteiro entre zero e dois, que especifica se os assets devem ser doestado "qualquer", "exportado"ou "por exportar";

• maxDuration - valor inteiro representativo da duração máxima, em segundos, queos assets devem ter;

• minDuration - valor inteiro representativo da duração mínimo, em segundos, que osassets devem ter;

• maxDate - análogo ao maxDuration, mas representa a data máxima dos assets;

• minDate - análogo ao minDuration, mas representa a data mínima dos assets;

• searchDateOption - valor inteiro entre zero e um, que especifica se os assets devemser procurados por data de entrada dos assets no sistema ou por data do asset. Éusado caso pelo menos um dos valores do maxDate e minDate sejam maiores quezero.

• lastPageIfNoResults - booleano que, caso seja verdadeiro, garante que pelo menosa última página de assets é retornada, que é útil caso seja pedido uma página maiordo que o número total de páginas disponíveis para uma dada pesquisa;

• orderOption - define a ordenação dos assets a serem retornados, ou seja, caso o valorseja zero é ascendente e caso seja um é descendente;

• page - define a página que queremos retornar da pesquisa. O número de páginastotal está associado ao valor do assetsPerPage, pois se existir mais assets que ovalor do assetsPerPage, irão existir mais do que uma página de resultados;

• sortOption - especifica o tipo de ordenação a ser usado, podendo variar entre asdatas do assets, datas de entrada no sistema, e duração dos assets.

A resposta ao pedido da listagem de assets, contém os seguintes parâmetros: totalRe-sults, que identifica o número de assets que correspondem à pesquisa; totalPages, valorrepresentativo do número total de páginas; page, número da página; assets, que será de-talhado em seguida. O parâmetro assets, contém assetInfos que, tal como o nome indica,contêm a informação de cada asset. O objecto assetInfo contém vários parâmetros sobreum dado asset, pelo que só irão ser detalhados os mais importantes no âmbito da UI:

• duration - duração em segundos;

57


Figura 4.1: Exemplo de um pedido inicial de listagem dos assets

• description - descrição sumária;

• proxyHTTPAddress - localização no servidor HTTP, da versão proxy do vídeo parapoder ser visualizado na UI;

• keyframeHTTPAddress - localização no servidor HTTP, do keyframe do vídeo;

• title - título do asset;

• GeneralMetadata - contém a metadata descriptiva do asset.

Ao entrar no newsRail, o utilizador tem à sua disposição os assets ordenados des-cendentemente por data, para que sejam mostrados os últimos assets. Como é possívelverificar na Figura 4.1, a listagem é pedida sem quaisquer restrições, à excepção do nú-mero de assets a serem retornados, nove.

A UI que é mostrada ao utilizador, pode ser dividida em 2 secções:

• lista dos assets situada à direita;

• menu de controlo situado à esquerda.

A página inicial dos assets contém até nove vídeos, e para cada vídeo é mostrado otítulo, duração, descrição e a data do asset, Figura 4.2. É possível pré-visualizar os ví-deos, através dos controlos nativos do HTML5. Cada asset, tem ainda associado uma

58


Figura 4.2: Exemplo de uma listagem inicial de assets

checkbox "Export"para determinar se deve ser ou não usado para exportação. Os butões"Select All"e "Clear Selected", permitem selecionar todos os assets que estão actualmentena UI para exportação ou limpar a selecção actual, respectivamente. O butão "Last Ex-port"permite que a exportação dos assets se inicie, utilizando as últimas configurações deexportação. O butão "Export"permite ao utilizador escolher uma ou mais configuraçõesde exportação, ou criar uma nova. Estes perfis serão melhor analisados na secção 4.2.4.

Os assets estão dispostos numa matriz três por três, para uma melhor disposiçãodo conteúdo, tendo em conta as restrições de espaço dos tablets. Sempre que existemmais que nove assets, a UI permite ao utilizador navegar pelas páginas através de gestos"swipe", tal como acontece nos sistemas operativos iOS e Android.

O menu de controlo, elemento-chave na filtragem, ordenação e pesquisa dos assets,será especificado em pormenor na próxima secção.

4.2.2 Filtragem, ordenação e pesquisa dos vídeos

A pesquisa e selecção das notícias é uma parte fundamental do workflow dos jornalis-tas. Tendo em conta este facto, o newsRail oferece um menu que permite manipular oscritérios de filtragem, ordenação e pesquisa.

Na parte superior do menu encontra-se um campo de pesquisa por palavras-chave,devidamente assinalado. Esta pesquisa aceita uma string que irá ser procurada nos várioscampos da classe assetInfo associada aos assets.

59


Em baixo do campo de pesquisa, aparecem os filtros. A UI disponibiliza contro-los para todos os parâmetros do pedido de listagem dos assets, excepto o assetsPerPage,lastPageIfNoResults, orderOption e sortOption, além do sessionId. Cada um destes pa-râmetros funciona como filtro, por exemplo, a maxDuration é um campo do tipo "time",no formato HH:MM:SS, para determinar um limite superior da duração dos assets. OHTML5 oferece novos tipos de inputs para os formulários, como é o caso do referido"time", que permitem ao browser restringir os valores introduzidos nos inputs.

A ordenação dos assets está directamente associada aos valores aceites pela orderOp-tion e pelo sortOption. Assim é possível ordenar pela duração dos assets ou pela data deentrada do asset no sistema ou ainda pela data do próprio asset, de forma ascendente oudescendente.

Sempre que é alterado um controlo, a lista de assets na UI é alterada e sincronizadatendo em conta a nova "query". O sincronismo é possivel através de pedidos tipo Ajax,mais propriamente através do uso da API XMLHTTPRequest, em conjunto com as tec-nologias HTML, CSS, DOM e JavaScript, pela comunicação com as interfaces REST. Omenu oferece ainda a possibilidade de criar vistas.

Figura 4.3: Vistas do newsRail

Vistas representam, à semelhança das views em base de dados, uma determinada"query" e permitem um paradigma de navegação similar às abas. Como tal, uma vistatem que estar sempre activa, pelo que tem que existir pelo menos uma na UI. A "query"pode ser um conjunto de filtros, ordenação e palavras-chave de pesquisa. Quando o utili-zador inicia uma nova sessão no newsRail, é-lhe mostrado uma vista default que contémtodos os últimos assets de forma indiscriminada.

60


A vista default é aquela a partir do qual, o utilizador pode criar uma nova vista, bas-tando para tal alterar os filtros, ordenação e pesquisa por palavras-chave e pressionar obutão "Create view", Figura 4.2. É também possível alterar vistas anteriormente criadas,modificando algum dos parâmetros da mesma.

O newsRail permite criar até quatro vistas, além da vista default, Figura 4.3. Além dacriação e alteração das vistas, a sua eliminação também é possível, à excepção da vistadefault, pois como foi referido anteriormente, é a única que permite originar novas vistas.As vistas que são criadas pelos utilizadores são guardadas através da API sessionStorage,pelo que só estão disponíveis durante a sessão.

4.2.3 Pré-visualização dos vídeos

Figura 4.4: Pré-visualização de um vídeo

Devido ao limitado espaço que a listagem de vídeos oferece para uma correcta pré-visualização de um vídeo, foi implementado um módulo dedicado à pré-visualização dosassets, Figura 4.4. Caso o utilizador pressione a àrea que contém a informação associadaao asset, é apresentado uma nova página. Esta página, contém o vídeo do asset associadoredimensionado e a informação do vídeo, que além de compreender a duração, título edescrição, é também mostra a sua metadata. Na parte inferior do módulo, são listados osassets relacionados, que são aqueles que estão actualmente contidos na vista que originoua pré-visualização.

É possivel seleccionar os vídeos para exportação através das checkboxes "Export",usar os butões "Select All"e "Clear Selected", bem como proceder à fase de exportação

61


através dos butões "Last Export"e "Export". O menu de controlo não foi incluído nestemódulo, dado que o seu objectivo é mostrar um vídeo com dimensões e metadata maisapropriadas, do que a presente na listagem dos assets.

4.2.4 Exportação dos vídeos

Figura 4.5: Menu de exportação de assets

A exportação dos vídeos para ambientes de edição é um dos requisitos essenciaisdo newsRail. O newsRail, através do Carbon Coder transcodifica os vídeos originaispara MXF OP1A, tipicamente numa ou mais pastas partilhadas - storages. A UI dá aoutilizador a possibilidade de escolher os destinos, que deseja usar para exportação.

O utilizador ao pressionar o butão "Export"é-lhe mostrada um menu, Figura 4.5. Sãodadas duas opções para exportação:

• selecção de storages previamente guardados;

• criação de um storage.

No contexto do newsRail, um storage é uma pasta partilhada que é definida pelosparâmetros: endereço do servidor, path dentro do servidor, nome do utilizador do SO erespectiva password para permitir que o Carbon Coder tenha permissões de escrita noservidor de destino e de leitura no servidor de origem dos vídeos. Assim, a criação denovo storage dependente destes quatro parâmetros.

62


Figura 4.6: Estados das exportações

Depois da selecção ou criação do storage, o newsRail gera um Flow, dos assets se-leccionados, para um ou mais destinos tal como explicado na secção 3.2.3. Para tal, a UIenvia um pedido ao middleware que contém:

• lista dos assets a serem exportados;

• identificação do Carbon Coder;

• storage de destino;

Se o pedido ao middleware for bem sucedido, a UI mostra uma nova página que con-tém o estado de cada exportação bem como a sua percentagem de conclusão, Figura 4.6.É possivel criar vistas como na listagem de assets, filtrar por estado de exportação: "Run-ning", "Completed", "Failed"e "Canceled". Cada asset actualmente a ser exportado, podeser cancelado através do butão "X". A UI oferece também os butões "Select All", "ClearSelected"e um butão "Delete"que apaga os assets seleccionados da interface do utilizador.

4.2.5 Configuração do newsRail

Para aumentar e melhorar a interoperabilidade do newsRail, a UI disponibiliza ummenu de configuração, que permite definir os storages, baskets, o Carbon Coder e osparâmetros do sistema. Actualmente só é possivel configurar os baskets, sendo permitidoo CRUD dos mesmos. Como cada basket está intrinsecamente associado a uma Rule,sempre que existem alterações nos baskets, a respectiva Rule é também alterada, apesar

63


Figura 4.7: Menu de configuração do sistema

de esta operação ser transparente ao utilizador. Se for acrescentado um novo basket aosistema, é também adicionada uma Rule para monitorizar o basket recentemente criado,o mesmo acontecendo para os baskets apagados. Uma Rule, à semelhança dos Flows,necessita do storage, da identificação do Carbon Coder, além do basket.

O menu de configuração é um página com um layout diferente quando comparadacom a restante UI. Em qualquer ponto do newsRail é possível aceder ao menu, pois asdefinições afectam todo o workflow do newsRail.

4.3 Testes

A framework JQuery Mobile oferece suporte para eventos activados por toque, mastambém por rato e teclado, para se efectuar testes enquanto não é possivel o uso da apli-cação num dispositivo móvel. Como tal, e enquanto o autor não teve acesso a um tablet, oprotótipo foi sendo testado no ambiente de desenvolvimento - computador de secretária.A implementação foi realizada por módulos, isto é, sempre que terminava um módulo, oautor começava o próximo e assim sucessivamente. Sempre que surgia alguma dificul-dade, eram analisadas as possíveis soluções e, dentro do possível, testadas no contexto doprotótipo.

No final foram realizados testes informais ao protótipo por colaboradores da MOGSolutions. O feedback foi, em geral, bastante positivo, principalmente por aqueles queestiveram presentes na Avaliação Heurística. Estes testes, demonstraram que houve uma

64


evolução no paradigma de interação do protótipo, evolução que não seria possível sem avaliosa Avaliação Heurística efectuada anteriormente.

4.4 Dificuldades encontradas

Durante o desenvolvimento do protótipo, foram surgindo obstáculos na implemen-tação e uso de determinadas funcionalidades. Algumas destas dificuldades surgiram naparte de integração entre a UI e o middleware. O middleware não estava preparado pararesponder a todas as particulariedades da UI orientado a tablets e principalmente às tec-nologias HTML 5 e JavaScript. No caso da geração dos proxies, e como foi escolhido oformato H.264/MPEG-4, o Carbon Coder e consequentemente o middleware teve de seralterado para acomodar este requisito. A implementação dos web services, na lado docliente, levantou inicialmente problemas devido à:

• política de segurança "same origin policy";

• implementação das interfaces REST não era sólida.

O "same origin policy"especifica que o browser deve bloquear scripts, como o JavaS-cript, que tentem aceder a métodos ou propriedades fora do domínio de origem do script[Doc11b]. Como o newsRail pretende ser um sistema distribuído para assim ter maisinteroperabilidade e flexibilidade, foram procuradas soluções para o problema.

A escolha recaiu no Cross-Domain Resource Sharing (CORS) [Doc11a]. O CORS éum Working Draft da W3C, e define que devem ser usados headers HTTP personalizadospara permitir que o browser se identifique junto do servidor, e este possa determinar se opedido pode ou continuar suceder-se. Existem dois tipos de pedidos: simples e preflight.Os primeiros usam somente métodos GET ou POST, e não especificam headers persona-lizados. Os pedidos do tipo preflight são aqueles que usam métodos diferentes de GET ouPOST, ou caso sejam POST tenham o header Content-Type diferente de application/x-www-form-urlencoded, multipart/form-data, ou text/plain. Os pedidos do newsRail sãotodos POST, pois é impraticável passar grandes quantidades de informação através doURL, e o seu conteúdo está em formato XML, pelo que estes são do tipo preflight.

Quando o cliente faz um pedido preflight, o browser envia primeiro um pedido OPTI-ONS com:

• Origin - origem do pedido;

• Access-Control-Request-Method - o método que pedido quer efectuar, POST nocaso do newsRail;

• Access-Control-Request-Headers - lista de headers personalizados a serem envia-dos;

65


O servidor, ao receber um pedido OPTIONS, deve analisar a Origin, Access-Control-Request-Method e Access-Control-Request-Headers. Depois de realizada a análise, oservidor deve enviar um pedido com:

• Access-Control-Allow-Origin - lista dos domínios com acesso permitido ao recurso;

• Access-Control-Allow-Methods - lista dos métodos permitidos

• Access-Control-Allow-Headers - headers permitidos;

• Access-Control-Max-Age - tempo, em segundos, que o pedido deve ficar em cache.

Caso a origem, métodos, e headers sejam permitidos, o browser prossegue ao pedidodo recurso que deseja. Como o middleware não estava preparado para receber pedidosOPTIONS, teve que ser alterado em conformidade.

As interfaces REST, apesar de testadas, ainda não tinham sido expostas a uma exten-siva utilização, pelo que foi necessário proceder a algumas alterações quanto ao conteúdoe formato das mensagens. As interfaces SOAP, por outro lado, já tinham sido expostas auma utilização mais exaustiva [Fer11].

O único problema que não foi corrigido em tempo útil, foi a actualização, em temporeal, dos assets em exportação. O middleware recebe eventos do Carbon Coder que in-formam sobre o estado de exportação do asset, percentagem de conclusão, entre outros,e disponibiliza-os em sockets TCP para quem estiver a escutá-los. A implementação desockets para linguagens script, como o JavaScript, é a API WebSockets, [W3C11c], e porser uma tecnologia recente, o middleware não estava preparado para acomodar a mesma.

4.5 Conclusões

No capítulo actual foram apresentados os aspectos mais relevantes da implementaçãoda UI . A implementação do protótipo começou por uma fase de análise e desenho daUI, que culminou na Avaliação Heurística. Em seguida efectuou-se o desenvolvimentopropriamente dito, que se prolongou até ao final do projecto. Algumas dificuldades ines-peradas foram aparecendo e sendo resolvidas, à excepção da já citada implementaçãodos WebSockets. O middleware do newsRail, apesar da sua estabilidade e eficiência deprocessos, oferecia certas restrições que foram sendo resolvidas à medida que foram apa-recendo. O protótipo é totalmente funcional, e possibilita realizar o workflow esperadodo newsRail: pesquisar, filtrar, ordenar e seleccionar os assets, pré-visualizar os vídeos, eexportá-los para um destino à escolha do utilizador.

66

Capítulo 5

Conclusões e Trabalho Futuro

É da mais elementar importância melhorar continuamente os processos de trabalhoda indústria de Televisão numa altura em que a Internet é usada com os mais variadosobjectivos: ver notícias, assistir a vídeos, comunicar com outras pessoas, entre outros. ATelevisão foi-se alterando ao longo dos tempos, em virtude das mudanças verificadas nassociedades, introduzindo mudanças inovadoras com o intuito de satisfazer os requisitoscada vez mais diferenciados dos telespectadores. Hoje em dia, a Televisão é bastantemais rica do que nas décadas anteriores, oferecendo maior diversidade de conteúdos efuncionalidades. Existem canais exclusivos de notícias, desporto ou arte para saciar osvários públicos. O próprio sistema electrónico é mais sofisticado, permitindo ver canaisem 1080p, manipular os conteúdos oferecidos ou aceder à Internet.

Os sistemas file-based estão hoje cada vez mais presentes nos workflows dos estúdios ecanais de Televisão, pois trazem vantagens e melhorias significativas às fases envolventesda produção de conteúdos televisivos. As TI oferecem novas possibilidades de gestão emanipulação dos conteúdos produzidos, pois as suas capacidades são mais-valias que nãopodem nem devem ser negligenciáveis. Além das vantagens das que as TI trazem aosworkflows de produção de material audiovisual, o formato MXF foi também um grandeimpulsionador dos sistemas baseados em ficheiros. A metadata assume um papel deextrema importância em ambientes de produção de televisão, quer para broadcasting querpara arquivamento. O MXF permite o transporte de metadata ao longo de todo o processo,desde a captura até ao arquivo e é agnóstico quanto ao esquema de compressão - codec.

A optimização dos processos de trabalho é uma das preocupações das indústrias, ea Televisão não é excepção. Para tal, são efectuados estudos e auditorias para assinalaras deficiências e incongruências dos workflows. A análise do workflow de produção denotícias da RTP, evidenciou algumas ineficiências possíveis de serem mitigadas, apesarde em geral ser um processo relativamente capaz. O newsRail é um sistema que corrigeas falhas identificadas e disponibiliza um conjunto de funcionalidades indispensáveis atodos os intervinientes do processo de produção de notícias.

67


A primeira parte da tese, consistiu na revisão do Estado da Arte que resultou numconjunto de conhecimentos de enorme valor para uma melhor percepção de todas as àreasenvolvidas. A análise da metodologia User Centered Design permitiu ao autor guiar o de-senvolvimento do protótipo funcional de uma forma mais clara e definida. As tecnologiasescolhidas foram desafiantes e motivadoras pois, apesar de estarem em fase de desen-volvimento, apresentam já um estado de maturação assinalável. O HTML5 e o restanteconjunto de tecnologias oferecem funcionalidades que até à bem pouco tempo só erampossíveis através de linguagens proprietárias como é o caso do Adobe Flash.

A segunda parte é formada por todo o processo que envolveu o desenvolvimento doprotótipo funcional da UI do newsRail. Numa primeira fase, foi necessário proceder àcompreensão do sistema, tendo sido analisados os requisitos que este deveria suportar bemcomo a sua arquitectura. Esta fase foi crucial para a criação dos mockups, pois sem umaclara definição do newsRail, estes não conseguiriam endereçar as imposições e restriçõesinerentes ao sistema. Estes mockups revelaram-se muito importantes para a concepçãoe implementação da UI, pois culminaram na realização da Avaliação Heurística. Numasegunda fase, procedeu-se à construção do protótipo, o que se relevou bastante trabalhosomas ainda mais gratificante. A terminar, foram realizados testes para aferir a usabilidadee funcionalidade de todo o projecto.

5.1 Objectivos cumpridos

O objectivo principal do projecto, desenvolvimento de um protótipo funcional, foicumprido com sucesso. O protótipo apresenta uma elevada flexibilidade, no que diz res-peito às plataformas a que se destina e todos os requisitos foram implementados, o quepossibilita a execução do workflow do newsRail. Inicialmente foram definidos os requisi-tos a que o protótipo deveria atender, nomeadamente:

• pesquisa e selecção dos assets;

• exportação dos assets seleccionados.

O utilizador inicialmente autentica-se, pesquisando posteriormente os assets que de-seja. Uma funcionalidade que se verificou de enorme interesse, foi a criação das vistas. Asvistas melhoram a navegação pelos vários baskets e assets. O utilizador tem ao seu disporfiltros que ajudam à selecção dos assets, como duração máxima dos assets ou conjuntode baskets a que os assets devem pertencer. É ainda possivel pré-visualizar os vídeos,característica essa que ajuda na correcta selecção dos vídeos a serem exportados.

No que diz respeito à exportação dos assets, a funcionalidade, apesar de implemen-tada, não possibilita a monitorização do estado dos assets exportados. Para tal, e como foireferido no capitulo anterior, o middleware teria que ser alterado em conformidade com

68


a tecnologia emergente WebSockets, o que não foi possível. Ainda assim, o protótipodisponibiliza um módulo para a monitorização dos assets em fase de exportação.

5.2 Trabalho futuro

Como foi afirmado no presente capítulo, o principal objectivo do projecto foi realizarum protótipo funcional da UI do newsRail, que foi cumprido. Apesar de não ser umproduto acabado, tal como indica a própria definição de protótipo, apresenta um estadode maturação e funcionalidade assinalável. Contudo, e como é natural, ainda precisa dealgumas afinações e melhoramentos. O aspecto mais óbvio é a implementação total domódulo de monitorização dos estados de exportação. Apesar da dependência intrínsecado middleware, seria desejável que o utilizador tivesse acesso, em tempo real, à evoluçãodos assets exportados.

As configurações do newsRail, disponíveis através do protótipo, só permitem o CRUDdos baskets. Apesar de disponível através das interfaces REST, o protótipo actualmentenão implementa o CRUD dos storages,nem a configuração das definições do Carbon Co-der. Ainda sobre as configurações do newsRail, o protótipo deveria também disponibili-zar, caso a base de dados esteja incompleta, um menu de primeira utilização. Este menupermitiria ao utilizador configurar as Rules, storages e o Carbon Coder. No estado actualdo protótipo, estas configurações têm que ser definidas manualmente.

A visualização da metadata, presente no módulo de pré-visualização do vídeo, é feitade forma indiscriminada e seria conveninente organizar os vários campos. A metadataassume um papel de particular importância em ambientes de produção de vídeo, pelo queé desejável que a disposição dos seus vários campos seja feita. Contudo, cada basketstem os seus próprios standards de definição da metadata, pelo que se torna difícil pre-ver quais os campos que estão contidos na metadata. Para os baskets conhecidos, seriadesejável configurar os campos que o utilizador desejasse visualizar através do menu deconfiguração do newsRail.

69

Referências

[10g11] 10gen. MongoDB, 2011. Disponível em http://www.mongodb.org/,acedido a última vez em 21 de Abril de 2011.

[App11] Apple. Thoughts on Flash, 2011. Disponível em http://www.apple.com/hotnews/thoughts-on-flash/, acedido a última vez em 10 deMare 2011.

[BN11] Raluca Budiu e Jakob Nielsen. Usability of iPad Apps and Websites 2ndedition. Technical report, Nielsen Norman Group, 2011.

[Boe88] B. W. Boehm. A spiral model of software development and enhancement.21:61–72, 1988.

[Bri11] Francisco Brito. SOA use in television systems. Master’s thesis, FEUP, 2011.

[Cor07] Quantum Corporation. File-based Workflows for Professional Video Archi-ves, Julho 2007.

[Dev02] Bruce Devlin. MXF - the Material Exchange Format. Technical report, Eu-ropean Broadcasting Union, 2002.

[Doc11a] MDN Docs. HTTP access control, 2011. Disponível em https://developer.mozilla.org/en/HTTP_access_control, acedido aúltima vez em 9 de Abril de 2011.

[Doc11b] MDN Docs. Same origin policy for JavaScript, 2011. Dis-ponível em https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript, acedido a última vez em 4 de Abril de 2011.

[DWBT06] Bruce Devlin, Jim Wilkinson, Matt Beard e Phil Tudor. The MXF Book:Introduction to the Material eXchange Format. Focal Press, 2006.

[Eck95] Wayne W. Eckerson. Three Tier Client/Server Architecture: Achieving Sca-lability, Performance, and Efficiency in Client Server Applications. In OpenInformation Systems 10, January 1995.

[ENP11] ENPS. Essential news production system, 2011. Disponível em http://www.enps.com/, acedido a última vez em 11 de Abril de 2011.

[Fer10] Pedro Ferreira. MXF - A progress report. EBU Technical Review, Julho2010.

70

http://www.mongodb.org/

http://www.apple.com/hotnews/thoughts-on-flash/

http://www.apple.com/hotnews/thoughts-on-flash/

https://developer.mozilla.org/en/HTTP_access_control

https://developer.mozilla.org/en/HTTP_access_control

https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript

https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript

http://www.enps.com/

http://www.enps.com/

REFERÊNCIAS

[Fer11] José Nuno Ferreira. Graphical User Interfaces for Television Production Soft-ware. Master’s thesis, FEUP, 2011.

[FEU11] FEUP. Interfaces Tácteis baseadas em HTML5, CSS3 e JavaScript, 2011.Disponível em https://www.fe.up.pt/si/ESTAGIOS_EMPRESAS.VER_DADOS_PROPOSTA?p_id=38738, acedido a última vez em 3 de Ja-neiro de 2011.

[For] EBU-SMPTE Joint Force. The EBU-SMPTE Joint Task Force for Harmo-nized Standards for the Exchange of Programme Material as Bit Streams –First Report: User Requirements.

[It11] Use It. Heuristic Evaluation, 2011. Disponível em http://www.useit.com/papers/heuristic/, acedido a última vez em 27 de Febreiro de2011.

[JM11] JQuery Mobile. JQuery Mobile, 2011. Disponível em http://jquerymobile.com/, acedido a última vez em 6 de Junho de 2011.

[Kov06] Al Kovalick. Video Systems in an IT Environment. Oxford: Focal Press,2006.

[Lab11a] Sencha Labs. JQTouch, 2011. Disponível em http://jqtouch.com/,acedido a última vez em 2 de Abril de 2011.

[Lab11b] Sencha Labs. Sencha Touch, 2011. Disponível em http://www.sencha.com/products/touch/, acedido a última vez em 6 de Abril de 2011.

[Mot11] Motionworks. CoSa lives: The story of the company behind Af-ter Effects, 2011. http://www.motionworks.com.au/2009/11/cosa-lives/, acedido a última vez em 30 de maio de 2011.

[MSD11] MSDN. Guid Structure, 2011. Disponível em http://msdn.microsoft.com/en-us/library/system.guid.aspx, acedido aúltima vez em 14 de Maio de 2011.

[O’R10] O’Reilly. What is Web 2.0, 2010. Disponível em http://oreilly.com/web2/archive/what-is-web-20.html, acedido a última vez em 10de Dezembro de 2010.

[Ove11] HTML5 Overview. FAQ, 2011. Disponível em http://dev.w3.org/html5/spec/Overview.html, acedido a última vez em 3 de Fevereirode 2011.

[Pil10] Mark Pilgrim. HTML5 Up And Running. O’Reilly Media, 2010.

[Pro11] Pencil Project. Evolus pencil, 2011. Disponível em http://pencil.evolus.vn/en-US/Home.aspx, acedido a última vez em 2 de Fevereirode 2011.

[Rev] Harvard Business Review. How internet junkies will save te-levision. Disponível em http://hbr.org/web/extras/how-internet-junkies-will-save-television/5-slide,acedido a última vez em 20 de Maio de 2011.

71

https://www.fe.up.pt/si/ESTAGIOS_EMPRESAS.VER_DADOS_PROPOSTA?p_id=38738

https://www.fe.up.pt/si/ESTAGIOS_EMPRESAS.VER_DADOS_PROPOSTA?p_id=38738

http://www.useit.com/papers/heuristic/

http://www.useit.com/papers/heuristic/

http://jquerymobile.com/

http://jquerymobile.com/

http://jqtouch.com/

http://www.sencha.com/products/touch/

http://www.sencha.com/products/touch/

http://www.motionworks.com.au/2009/11/cosa-lives/

http://www.motionworks.com.au/2009/11/cosa-lives/

http://msdn.microsoft.com/en-us/library/system.guid.aspx

http://msdn.microsoft.com/en-us/library/system.guid.aspx

http://oreilly.com/web2/archive/what-is-web-20.html

http://oreilly.com/web2/archive/what-is-web-20.html

http://dev.w3.org/html5/spec/Overview.html

http://dev.w3.org/html5/spec/Overview.html

http://pencil.evolus.vn/en-US/Home.aspx

http://pencil.evolus.vn/en-US/Home.aspx

http://hbr.org/web/extras/how-internet-junkies-will-save-television/5-slide

http://hbr.org/web/extras/how-internet-junkies-will-save-television/5-slide

REFERÊNCIAS

[RSP02] Y. Rogers, H. Sharp e J. Preece. Interaction Design: Beyond Human-Computer Interaction. John Wiley and Sons Ltd, 2002.

[SMPa] SMPTE. SMPTE 336m-2004: Data Encoding Protocol Using Key-Length-Value.

[SMPb] SMPTE. SMPTE 377–1m–2009: Material Exchange Format (MXF) – FileFormat Specification (Standard).

[SMPc] SMPTE. SMPTE 379-1-2009: Material Exchange Format – Generic Contai-ner.

[Sol10a] MOG Solutions. File-based Ingest, 2010. Disponível emhttp://www.mog-technologies.com/products/file-based/product-overview/, acedido a última vez em 20 de Novembro de 2010.

[Sol10b] MOG Solutions. SDI-Recorder Ingest, 2010. Disponível em http://www.mog-technologies.com/products/sdi-recorder/product-overview/, acedido a última vez em 20 de Novembro de 2010.

[Sol11] MOG Solutions. MOG Solutions, 2011. Disponível em http://www.mog-solutions.com/index2.php, acedido a última vez em 20 de Ja-neiro de 2011.

[Sys11a] Adobe Systems. Adobe Flash Player, 2011. Disponível em http://www.adobe.com/products/flashplayer/, acedido a última vez em 29 deJaneiro de 2011.

[Sys11b] Adobe Systems. Flash Player Features, 2011. Disponível em http://www.adobe.com/products/flashplayer/features/, acedido aúltima vez em 29 de Janeiro de 2011.

[Tec] MOG Technologies. Awards. Disponível em http://www.mog-technologies.com/company/awards/, acedido a última vez em10 de Maio de 2011.

[UMI] SMPTE 330m-2004: Unique Material Identifier (UMID).

[Use11] When Can I Use... Compatibility tables for support of HTML5, CSS3, SVGand more in desktop and mobile browsers., 2011. Disponível em http://caniuse.com/, acedido a última vez em 14 de Junho de 2011.

[W3C98] W3C. 2 - A History of HTML, 1998. Disponível em http://www.w3.org/People/Raggett/book4/ch02.html, acedido a última vez em 2de Fevereiro de 2011.

[W3C11a] W3C. CSS current work & how to participate, 2011. Disponível em http://www.w3.org/Style/CSS/current-work, acedido a última vez em24 de Mare 2011.

[W3C11b] W3C. Web Workers, 2011. Disponível em http://dev.w3.org/html5/workers/, acedido a última vez em 5 de Fevereiro de 2011.

72

http://www.mog-technologies.com/products/file-based/product-overview/

http://www.mog-technologies.com/products/file-based/product-overview/

http://www.mog-technologies.com/products/sdi-recorder/product-overview/



http://www.mog-solutions.com/index2.php

http://www.mog-solutions.com/index2.php

http://www.adobe.com/products/flashplayer/

http://www.adobe.com/products/flashplayer/

http://www.adobe.com/products/flashplayer/features/

http://www.adobe.com/products/flashplayer/features/

http://www.mog-technologies.com/company/awards/

http://www.mog-technologies.com/company/awards/

http://caniuse.com/

http://caniuse.com/

http://www.w3.org/People/Raggett/book4/ch02.html

http://www.w3.org/People/Raggett/book4/ch02.html

http://www.w3.org/Style/CSS/current-work

http://www.w3.org/Style/CSS/current-work

http://dev.w3.org/html5/workers/

http://dev.w3.org/html5/workers/

REFERÊNCIAS

[W3C11c] W3C. The WebSocket API, 2011. Disponível em http://dev.w3.org/html5/websockets/, acedido a última vez em 4 de Junho de 2011.

[Web11] Read Write Web. Android usage increased 200% over past 3 months,2011. Disponível em http://www.readwriteweb.com/archives/android_usage_increased_200_percent_over_past_three_months.php, acedido a última vez em 19 de Janeiro de 2011.

[WHA11a] WHATWG. Faq, 2011. Disponível em http://wiki.whatwg.org/wiki/FAQ, acedido a última vez em 2 de Fevereiro de 2011.

[WHA11b] WHATWG. FAQ, 2011. Disponível em http://wiki.whatwg.org/wiki/FAQ, acedido a última vez em 24 de Abril de 2011.

[Wor10] How Stuff Works. Is there a Web 1.0?, 2010. Disponível em http://computer.howstuffworks.com/web-101.htm, acedido a última vezem 10 de Dezembro de 2010.

73

http://dev.w3.org/html5/websockets/

http://dev.w3.org/html5/websockets/

http://www.readwriteweb.com/archives/android_usage_increased_200_percent_over_past_three_months.php



http://wiki.whatwg.org/wiki/FAQ




http://computer.howstuffworks.com/web-101.htm

http://computer.howstuffworks.com/web-101.htm

Anexo A

Guião da Avaliação Heurística

This usability test will focus on the mobile (tablets) edition of newsRail. The test willbe performed on a desktop browser with mouse as the input, but the interaction mode in atablet is quite different, so please take that in consideration when reviewing the mockups.

A.1 newsRail

newsRail provides a single point of access for filtering, previewing and exporting clipsfrom various agencies news using a ingest system, i.e. mxfSPEEDRAIL F1000. Theseconverted clips are available to the local editing system.

A.2 Use cases

The following list shows possible tasks that can be performed with newsRail:

• Search Assets

• View Asset List

• Filter/Sort Asset List

– “Arrival” date– Recording date– Seen/New Asset– Duration– Source

• Preview Asset

– View Asset Proxy– View Asset Metadata– View Original Asset Location

• Export Assets

• System configuration

74


– General configuration– User settings– Configure Baskets– Configure Outputs

• Login

• Manage Custom Searches

A.3 Scenarios

Scenario 1 - Preview

1. Login

2. Preview a particular Asset from the list

3. Logout

Scenario 2 – View One Basket

1. Login

2. View only the assets from “Basket 2”

3. Logout

Scenario 3 - Filter

1. Login

2. Filter the Asset List by “Recording date”

3. Logout

Scenario 4 – Export clips

1. Login

2. From the list of assets, export the clips that are already checked

3. Logout

Scenario 5 – Filter exports

1. Login

2. Go to list of exports

3. Cancel a export that is already running

4. Filter the export actions by “Complete”

5. Logout

75


Scenario 6 - Show by

1. Login

2. Go to list of exports

3. View only the exports that are running

4. Logout

Scenario 7 - Search Basket 2

1. Login

2. Search in Tab Basket 2

3. Return to the view of all assets

4. Logout

Scenario 8 – View and Export

1. Login

2. Preview an clip

3. Export the clips that are already checked

4. Logout

A.4 Test Goals

• Identify usability problems in the user interface

• Identify the good aspects in the user interface

A.5 Test Conditions

1. Browser – Mozilla Firefox (Google Chrome/Safari doesn’t work quite well with the.html).

2. Most of the items/buttons are clickable, but some exist only for visualization purpo-ses.

3. You should be able to conclude each scenario.

4. Input values are not possible because each “page” is an image with clickable “but-tons”, so don’t try to enter values on forms/checkboxs.

76


A.6 Evaluator activities

A.6.1 Evaluating newsRail (individual)

1. Try to complete each scenario on your own with no external help.

2. Identify and list any areas of the system that you feel are counter to the heuristics.List all of the concerns that you note, including what seems to be duplicate. Be sureto clearly describe what you find, including where in the system it was found.

3. Perform the user actions that you feel would be taken to perform the scenarios.

4. Follow the plan (user scenarios).

5. Do not ask about the user interface.

A.6.2 Analyzing the results (group)

1. Review each of the concerns noted by each of the evaluators. Make sure that eachconcern is clearly understood by all evaluators.

2. Develop an affinity diagram that groups similar concerns.

3. Evaluate and judge each concern for its compliance with your defined heuristic.

4. Assign a severity level for each grouped concern based on the impact to the end user(see Severity Rating section).

5. Determine recommendations to fix the problem. Make sure each recommendationlinks the heuristic and a design principle.

77

interfaces tácteis baseadas em...

Documents