Ultra TV Deliverable · • Barra de duração e percentagem visualizada • Data e hora de...

Ultra TV

Deliverable

Deliverable 5.1 Guidelines de Design Gráfico e de Interação da UI

Versão:

Data:

Distribuição:

Responsável:

V2

30/06/2018

Pública

Universidade de Aveiro

Guidelines de Design Gráfico e de Interação da UI 3

Sumário Executivo O presente documento reúne e sistematiza um conjunto de orientações gráficas e de interação

centradas sobre a UX, resultantes da recolha e análise de casos, já abordados nos documentos D2.3,

D4.1 e D4.3, a par do acompanhamento atento de melhores práticas, novos lançamentos e iterações

de produtos existentes. Tais recomendações são sustentadas por critérios paradigmáticos de Material

Design e de grandes plataformas como a Apple tvOS e Android TV, juntamente com as limitações

das diversas tipologias de dispositivos. Deste modo, o documento apresenta um conjunto de

guidelines gráficas (layout e grelhas, tipografia, paleta cromática e texturas visuais) e de interação

(navegação, animações e transições), relativas ao design da UI e UX do protótipo final. São

igualmente incluídas guidelines de implementação do UltraTV em STB com recurso à Framework

Luna, com referência ao frontend e backend do sistema, que asseguram a consistência em futuros

desenvolvimentos do protótipo.

4 Guidelines de Design Gráfico e de Interação da UI

Histórico de Revisões

Versão Data Comentários

V1 30/11/2017 Versão à data prevista

V2 30/06/2018 Versão final


Acrónimos

MON Managed Operated Network

OTT Over-The-Top

PC Portable Computer

STB Set-Top-Box

TV Television

UI User Interface

UX User eXperience

VoD Video-on-Demand (Vídeo a Pedido)


Índice de Figuras

Figura 1 – Captura de ecrã de organização de versões por pasta na plataforma Sharepoint ..............12

Figura 2 – Exemplos de nomes de ficheiros – Vx_Tipo de fidelidade/momento de avaliação_xxx.png ........................................................................................................12

Figura 3 - Wireframe da interface homescreen ......................................................................................13

Figura 4 - Tamanho em pixéis dos elementos "card ativo" e "thumbnail" no homescreen ....................14

Figura 5 - Base para "card ativo" ...........................................................................................................14

Figura 6 - Estrutura de navegação e entrada no silo .............................................................................14

Figura 7 - Família Roboto em uso – medidas em px .............................................................................15

Figura 8 - Paleta cromática ....................................................................................................................16

Figura 9 - Estados de ícone "Favorito" – inativo, ativo, em foco, selecionado, selecionado em foco ...............................................................................................................................16

Figura 10 - Estados de ícone "Filtro" – inativo, ativo, em foco, selecionado, selecionado em foco ......16

Figura 11 - Família de ícones UltraTV ...................................................................................................17

Figura 12 - Família de ícones do controlo temporal UltraTV .................................................................17

Figura 13 - Exemplos de mudança de seleção no menu ervilha contextual ..........................................18

Figura 14 - Rótulos atribuídos aos conteúdos........................................................................................18

Figura 15 - Equipamento xiaomi – Mi Box - Android 6.0 TV Box ...........................................................19

Figura 16 - Menu principal ativo – Botão "O Meu Conteúdo" em foco ..................................................20

Figura 17 - Menu principal ativo – Segundo perfil em foco ....................................................................20

Figura 18 - Menu Filtro ativo - Checkbox "FB Videos" em foco .............................................................21

Figura 19 - Menu contextual ativo - Feedback da ação "Adicionar aos favoritos" .................................21

Figura 20 - Menu temporal ativo - Botão de avanço 30 segundos em foco ..........................................22

Figura 21 - Indicação visual de zapping e canal/conteúdo a ser visualizado ........................................22

Figura 22 - Arquitetura de sistema .........................................................................................................25

Figura 23 - Arquitetura de sistema .........................................................................................................25

Figura 24 - Splash Screen....................................................................................................................26

Figura 25 – Homescreen ........................................................................................................................28

Figura 26 - Silo 'Tv Direto' ......................................................................................................................28

Figura 27 - Controlos player de vídeo ....................................................................................................29

Figura 28 - Menu contextual ...................................................................................................................29

Figura 29 - Menu lateral 'Sugeridos' .......................................................................................................30

Figura 30 - Search ..................................................................................................................................31

Figura 31 - Search com resultados ........................................................................................................32

Figura 32 - Filtros ...................................................................................................................................33

Figura 33 - Favoritos ..............................................................................................................................34

Figura 34 - 'Continuar a ver' ...................................................................................................................34

Figura 35 - 'Mais info' .............................................................................................................................35


Índice de Conteúdos

Histórico de Revisões .......................................................................................................... 4

Introdução ..................................................................................................................... 11

Guidelines do protótipo UltraTV .................................................................................. 13

2.1 Guidelines gráficas ...............................................................................................................13

2.1.1 Layout e grelhas ....................................................................................................... 13 2.1.2 Tipografia .................................................................................................................. 15 2.1.3 Paleta cromática e visual .......................................................................................... 15

2.2 Guidelines de interação........................................................................................................18

2.2.1 Navegação ............................................................................................................... 19 2.2.2 Animações e transições ........................................................................................... 23

2.3 Guidelines de implementação .............................................................................................23

2.3.1 Protótipo com versão em inglês ............................................................................... 24 2.3.2 Arquitetura de sistema .............................................................................................. 24 2.3.3 Frontend ................................................................................................................... 26 2.3.4 Backend .................................................................................................................... 26 2.3.5 Splash screen ........................................................................................................... 26 2.3.6 Homescreen ............................................................................................................. 27 2.3.7 Fullscreen ................................................................................................................. 29 2.3.8 Pesquisa ................................................................................................................... 31 2.3.9 Filtros ........................................................................................................................ 32 2.3.10 O meu conteúdo ....................................................................................................... 33 2.3.11 Mais info ................................................................................................................... 34 2.3.12 Outros aspetos relevantes relativos à implementação técnica ............................... 35

Conclusão ..................................................................................................................... 40

Deliverable 5.1


Introdução O presente documento recolhe e arquiva os principais momentos no desenvolvimento da Interface

de Utilizador (UI), estando articulado com as orientações gráficas e de interação descritas no

documento Milestone 5.1. "Estabelecimento de Guidelines de Design Gráfico e de Interação da UI

adequados às diversas tipologias de aplicações e dispositivos a suportar" e nos resultados dos

momentos de avaliação relatados no Deliverable 8.1 "Resultados da Avaliação da User Experience

(UX)".

As imagens consideradas relevantes para a demonstração do processo de design e

implementação iterativo dividem-se nas várias fases projetuais, sendo este iniciado por esboços e

mockups de baixa fidelidade, seguindo-se mockups de média e alta fidelidade, e terminando em

diferentes versões prototipadas. Para sua consulta rápida, e tratando-se de um agregado significativo

de imagens, estas foram armazenadas na sua totalidade na plataforma SharePoint, estando

organizadas por versão gráfica da interface.

As imagens foram ainda identificadas com a versão de UI e/ou implementação a que pertencem,

partindo da versão inicial (V1) até à versão final (V5), cujas características e racionais serão

ilustradas e relatadas nas diferentes secções deste documento. Adicionalmente, as imagens foram

rotuladas com tags referentes à sua fidelidade, partindo dos esboços de baixa fidelidade (drafts,

lowfidelity), a mockups de média e alta fidelidade (mediumfidelity, highfidelity) ou a versões de teste

utilizadas em momentos de avaliação ou apresentação pública.

Estas tags foram atribuídas, quanto à sua fidelidade:

• Drafts – fotografias ou digitalizações de esboços feitos à mão em papel ou em quadro branco;

• Lowfidelity – mockups a escala real de baixa fidelidade, desenhados no computador (em

Illustrator, Sketch), sem atributos visuais e apenas com elementos sumários pertencentes à

experiência de utilizador;

• Mediumfidelity – mockups a escala real de média fidelidade, desenhados no computador

(Sketch), com imagens placeholder e alguns atributos visuais (aplicações cromáticas, etc.);

• Highfidelity – mockups a escala real de alta fidelidade, desenhados no computador (Sketch),

com imagens placeholder representativas de casos reais, com atributos visuais representativos do

look & feel final, e todos os elementos gráficos e de interação necessários para a sua transposição

para a implementação;

• Elementos – elementos gráficos estáticos (formato .png), desenhados no computador (Sketch),

e utilizados na implementação de versões dinâmicas Luna.

E quanto à sua versão de implementação e/ou momento de avaliação:

• Peritos – UIs referentes ao protótipo Marvel avaliado por peritos em junho de 2017, em formato

de exploração orientada;

• Luna InLab – capturas de ecrã referentes ao protótipo Luna avaliado em laboratório em julho

2017 por 20 participantes, em formato de exploração livre de conteúdos locais;

• Luna jAUTI – capturas de ecrã referentes ao protótipo Luna apresentado em demonstração na

conferência jAUTI em outubro 2017, assente em conteúdos MEO dinâmicos;

• Luna FT – capturas de ecrã referentes ao protótipo Luna utilizado na avaliação de campo (Field

Trial) através de 20 STBs Xiaomi em janeiro 2018, assente em conteúdos MEO, YouTube e

Facebook dinâmicos;

Deliverable 5.1


• Luna Pos-FT – capturas de ecrã referentes ao protótipo Luna utilizado na fase final da

avaliação de campo (Field Trial) através de 6 STBs Xiaomi em fevereiro 2018, assente em conteúdos

MEO, YouTube e Facebook dinâmicos;

Figura 1 – Captura de ecrã de organização de versões por pasta na plataforma Sharepoint

Figura 2 – Exemplos de nomes de ficheiros – Vx_Tipo de fidelidade/momento de avaliação_xxx.png

Deliverable 5.1


Guidelines do protótipo UltraTV As guidelines do ecossistema UltraTV pretendem ser um conjunto de guias e recomendações

direcionadas para o desenho de uma interface para iTV com uma abordagem content-first.

O conteúdo, no formato de imagem ou vídeo, assume uma presença central, conduzindo o olhar e

atenção do utilizador para uma vasta escolha de propostas, remetendo as restantes funcionalidades

para papéis secundários nos limites da interface.

O sistema desdobra-se em funcionalidades que proporcionam e facilitam o acesso a conteúdos

recomendados, alimentando a personalização da experiência de utilizador.

2.1 Guidelines gráficas

Contemporânea e sóbria, a interface gráfica do protótipo UltraTV é construída sobre formas

orgânicas, cores jovens e uma grelha dinâmica de conteúdo.

2.1.1 Layout e grelhas

A grelha disponibiliza um conteúdo em foco e até 19 thumbnails em simultâneo. Presente no

homescreen, esta é replicada também nos silos de conteúdos e na secção "O Meu Conteúdo".

Apresenta cinco colunas de conteúdo, com os respetivos títulos e o menu principal na parte

superior da interface. A coluna central serve de destaque para o foco do utilizador.

Figura 3 - Wireframe da interface homescreen

O card ativo apresenta dimensões 4 vezes maiores que o thumbnail, mostrando claramente o foco

e o card assinalado, tapando em parte os thumbnails circunscritos.

A grelha permite o conteúdo "respirar", deixando espaço negativo entre os vários thumbnails. A

exceção é a sobreposição do card ativo.

Deliverable 5.1


Figura 4 - Tamanho em pixéis dos elementos "card ativo" e "thumbnail" no homescreen

O card ativo é composto, em ordem de cima para baixo, por:

• Rótulo de tipo de conteúdo (ex. favorito)

• Título do conteúdo

• Sub-título do conteúdo

• Barra de duração e percentagem visualizada

• Data e hora de publicação na fonte MEO/canal ou rede social

• Logótipo da fonte

Figura 5 - Base para "card ativo"

A grelha apresenta conteúdo discriminado pelas preferências do utilizador, com a exceção do 5º e

10º cards da homescreen. Em todas as colunas, exceto a coluna Netflix, estes espaços apresentam

o card "ver mais", que serve como entrada num silo de conteúdos adicionais daquele tipo.

Figura 6 - Estrutura de navegação e entrada no silo

Deliverable 5.1


2.1.2 Tipografia

Categorizada como uma família não serifada neo-grotesca, a Roboto foi desenvolvida pela

Google como fonte de sistema para os seus dispositivos Android. A Google descreve a fonte como

"moderna, mas acessível"1. Por estar abrangida pela licença Apache, a Roboto está disponível para

qualquer implementação web através do protocolo Google Fonts.

A fonte foi apenas utilizada nos pesos Medium e Regular, recorrendo às maiúsculas para novos

estilos. Os tamanhos variam entre os 36px e os 12px, de modo a hierarquizar conteúdo textual, e

equilibrando-o para o utilizador.

Figura 7 - Família Roboto em uso – medidas em px

2.1.3 Paleta cromática e visual

O uso de cores vivas e uma paleta contrastante com o tom escuro geral criam o look & feel

contemporâneo e jovem para a audiência alvo pretendida. Aliada a essa paleta cromática, a interface

recorre a sombras de modo a facilitar a leitura visual de elementos e ações.

1 https://www.engadget.com/2011/10/18/roboto-and-the-new-design-philosophy-of-android-4-0-ice-cream-s/

Deliverable 5.1


Figura 8 - Paleta cromática

Visualmente, a interface recorre à mudança de escala e de cor para claramente indicar ao

utilizador o foco ativo. É particularmente importante esta alteração na escolha de botões que levam

ao acionar de funcionalidades ou à mudança de interface. Por esta razão, é aplicada uma mudança

cromática à base dos menus "ervilha" (Figura 13), e um aumento de escala, opacidade, stroke (linha)

e fill (preenchimento) aos ícones (Figura 9 / Figura 10), na escolha de funcionalidades.

Figura 9 - Estados de ícone "Favorito" – inativo, ativo, em foco, selecionado, selecionado em foco

Figura 10 - Estados de ícone "Filtro" – inativo, ativo, em foco, selecionado, selecionado em foco

O conjunto de ícones desenhados pretende refletir as tendências gráficas atuais, recorrendo a

uma linha fina não fechada, que constrói uma forma única de modo simples e minimalista. Os ícones

pretendem ser legíveis e inequívocos, transmitindo claramente a sua função, tendo sido testados

nesse sentido previamente.

Foram desenhados ícones correspondendo às diferentes funcionalidades (da esq. para a direita,

Figura 11):

• hora/data de publicação,

• área "O Meu Conteúdo",

• área "Filtro",

• área "Pesquisa",

• área "Definições",

• recomeçar,

• favorito,

• gravar,

Deliverable 5.1


• "não quero ver",

• mais informação,

• "Continuar a ver",

• não existe informação,

• ocorreu um erro,

• atualização,

• ajuda;

Figura 11 - Família de ícones UltraTV

Figura 12 - Família de ícones do controlo temporal UltraTV

Os ícones são, na sua maioria, apresentados sob um menu ou elemento gráfico. No caso do

menu contextual, são acompanhados por um feedback textual da ação que cumprem, surgindo por

debaixo do elemento selecionado.

Deliverable 5.1


Figura 13 - Exemplos de mudança de seleção no menu ervilha contextual

A paleta cromática selecionada foi também aplicada aos rótulos atribuídos ao conteúdo,

hierarquizando prioridades transmitidas pelos utilizadores, da mais importante (com o tom mais clara)

à menos importante (com o tom mais escuro). As funcionalidades "Continuar a ver" e "Favoritos" são

apresentadas em rótulos com uma cor mais chamativa e contrastante com o tema escuro da UI,

enquanto que os conteúdos "Relacionados" ou "Sugeridos" são apresentados em tons escuros,

passando mais desapercebidos ao olhar do utilizador.

Figura 14 - Rótulos atribuídos aos conteúdos

2.2 Guidelines de interação

O protótipo UltraTV foi implementado numa box Android 6.0 Mi Box 4K UltraHD. O setup à

televisão é feito através de um cabo HDMI com ligação à internet wireless.

O comando apresenta um design minimalista, com 4 teclas direcionais (← → ↑ ↓), um botão

ON/OFF, back ← (regressar), home ◯, microfone, controlo de volume ( + / – ), e um OK. Esta

limitação de teclas, distante do cenário atual no telecomando MEO, apresentou alguns desafios de

interação, levando à simplificação de modelos e ações.

No protótipo UltraTV a tecla microfone foi tapada com um círculo branco, sendo utilizada como

tecla MENU. A tecla home ◯ está inativa no protótipo já que não é possível retirar-lhe a função de

regresso ao home da box Android, o que levaria o utilizador a sair do sistema UltraTV.

Deliverable 5.1


Figura 15 - Equipamento xiaomi – Mi Box - Android 6.0 TV Box

2.2.1 Navegação

A navegação nas interfaces é feita, na sua generalidade, com as teclas direcionais, a tecla OK e a

tecla back. Adicionalmente, o acesso ao menu é feito através da tecla MENU (tecla microfone),

apenas sendo possível em interfaces de fullscreen ou homescreen.

O acesso ao menu (Figura 16) no homescreen é possível através da tecla MENU ou a partir da

primeira linha de conteúdo, na tecla cima ↑. O primeiro elemento selecionado é o perfil ativo, sendo

necessário recorrer às teclas direcionais para selecionar outras funcionalidades. O acesso é depois

feito através da tecla OK. A qualquer momento o utilizador pode regressar à grelha através da tecla

back.

Deliverable 5.1


Figura 16 - Menu principal ativo – Botão "O Meu Conteúdo" em foco

Seguindo este modelo de interação, a mudança de perfil é feita recorrendo às teclas direcionais e

à tecla OK. A partir do OK no perfil selecionado, os restantes ícones são substituídos pelos perfis

existentes. O menu comporta-se visual e interactivamente da mesma forma permitindo uma mudança

de perfil rápida e simples.

Figura 17 - Menu principal ativo – Segundo perfil em foco

Na área Filtro é adotado um modelo de interação por checkbox, permitindo ao utilizador

selecionar as colunas ativas no seu homescreen através de um toggle de check ou caixa vazia. A

ação é aplicada quando regressado à grelha através do botão back. Existe ainda uma opção de

selecionar "todas" as colunas, desenhado de forma a facilitar o regresso ao modelo em que todas as

colunas estão ativas e a ser apresentadas.

Duas indicações textuais não selecionáveis são apresentadas no topo e fundo da caixa de Filtro,

transmitindo de forma clara o feedback esperado desta interface.

Deliverable 5.1


Figura 18 - Menu Filtro ativo - Checkbox "FB Videos" em foco

O mesmo modelo de interação do menu principal repete-se em fullscreen para aceder ao menu

contextual. Através da tecla MENU, o menu contextual surge na parte superior da interface, com a

opção "favorito" em foco. Indicações textuais são apresentadas correspondendo ao ícone em foco, e

adicionalmente, quando uma ação é tomada pelo utilizador, na parte superior do ecrã.

Figura 19 - Menu contextual ativo - Feedback da ação "Adicionar aos favoritos"

O controlo temporal é ativado através do OK, seguindo standards de interação de produtos

semelhantes. Devido ao comando minimalista que restringe o uso de teclas para diferentes ações, as

teclas correspondentes aos avanços e recuos temporais (fast forward e rewind) foram substituídos

por botões selecionáveis na parte inferior do ecrã. Nesse sentido, foram atribuídos a estes botões

diferentes métricas, claramente indicando ao utilizador o tempo em segundos de avanço ou recuo.

Deliverable 5.1


Optou-se por definir períodos de 15 e 30 segundos para um maior controlo de tempo, ao invés dos 7

e 30 segundos estabelecidos na STB MEO. A barra indica ainda a hora de início e fim, e o momento

de visualização. Em conteúdos gravados ou provenientes de fontes OTT, a hora de início é mostrada

como 00:00:00, sendo mostrado a sua duração total no fim da barra.

Após inatividade do utilizador, a barra de controlo temporal desaparece ao fim de alguns

segundos.

Figura 20 - Menu temporal ativo - Botão de avanço 30 segundos em foco

O retirar da navegação tradicional por canal implicou a colocação de um cabeçalho informativo

bem visível e claro na parte superior da interface após a entrada num canal ou conteúdo diferente.

De modo a informar claramente o utilizador onde se encontra, o cabeçalho mostra um pequeno

thumbnail (imagem representativa), o título, a hora de emissão e o canal de origem.

Este cabeçalho desaparece após alguns segundos de inatividade por parte do utilizador.

Figura 21 - Indicação visual de zapping e canal/conteúdo a ser visualizado

Deliverable 5.1


2.2.2 Animações e transições

As animações utilizadas no protótipo UltraTV foram aplicadas com recurso à biblioteca Luna de

animações e transições existentes. Desta forma, o processo foi agilizado de forma a que o protótipo

não apresentasse problemas de reprodução na ativação de animações, não prejudicando a

performance introduzida pela framework Luna.

No entanto, é de realçar que a utilização desta biblioteca limitou o uso de animações que não

estivessem previstas pela framework, reduzindo as possibilidades de transições e efeitos. Foi o caso

dos menus principal e contextual que alternam simplesmente entre imagens estáticas, não tendo sido

possível implementar uma transição mais natural e orgânica entre os vários estados.

De modo geral, as animações são feitas de forma suave, recorrendo a diferenças de opacidade

quando a transição é de elementos contrastantes. O alternar de escalas e posições é apresentado

através de animações de deslize (slide), utilizando os vários elementos gráficos para esconder e

apresentar conteúdos.

Exemplos de animações e transições utilizadas podem ser visualizadas nos seguintes vídeos:

Vídeo 1

• loading,

• navegação entre cards e na grelha,

• entrada no silo,

• entrada no conteúdo e zapping,

• barra lateral e navegação na barra lateral,

• entrada em menu contextual,

• navegação no menu contextual,

• adicionar aos favoritos,

• entrada e navegação no item de catálogo,

• acesso ao menu principal,

• mudança de perfil,

Vídeo 2

2.3 Guidelines de implementação

Relembrando que um dos objetivos, anteriormente referido, é o de suportar o ecossistema de

aplicações em normas e plataformas abertas, o processo de prototipagem, relatado neste

documento, foi desenvolvido com recurso a JavaScript e nodeJS. Esta linguagem (JavaScript) e este

interpretador de código (nodeJS) representam a camada de base para a stack de tecnologias

escolhidas para o desenvolvimento. Neste sentido, o processo de implementação, referente às

tarefas de prototipagem, tornou-se mais ágil e mais livre em virtude do carácter aberto das

tecnologias em questão.

Dentro da stack de tecnologias, interessa destacar e descrever a principal ferramenta utilizada

para a prototipagem das user interfaces: Luna. Luna nasce no seio de uma empresa dinamarquesa

(Craftwork) fundada em 2003. A Craftwork foca-se no desenvolvimento de EPG’s e de aplicações

interativas para grandes broadcasters reconhecidos na indústria.

https://alticelabs-my.sharepoint.com/:v:/g/personal/bernardo_alticelabs_onmicrosoft_com/ERvIKAfxIM9MuglMpA7eCYoBSVkeDrtDy2Ah7dpEvfGEBA?e=3CFrLM

https://alticelabs-my.sharepoint.com/:v:/g/personal/bernardo_alticelabs_onmicrosoft_com/ESFzpMnaIz5Cv8iPUjPNzVMBigMeRjpV1wW4xBg1OQGtdA?e=D738I0

Deliverable 5.1


Luna é um motor de uma aplicação otimizada para o desenvolvimento de UI’s orientadas para o

contexto das televisões e considerado um TV Browser capaz de superar, em termos de performance,

qualquer outro browser disponível no que diz respeito ao raw speed da user interface e ao tempo de

implementação dos produtos.

Esta ferramenta constitui um ramo (branch) de Node.js: um interpretador de código JavaScript

que é executado do lado do servidor, criado sobre o mecanismo Google V8 com um processo de

compilação ‘just-in-time’.

Luna inclui um motor gráfico acompanhado de uma API orientada ao desenvolvimento de TV user

interfaces. Considerado um ‘TV Browser’, o Luna permite uma maximização da performance do GPU

quando comparado com outros browsers HTML5.

Em termos gráficos, apresenta como principais facilidades: a renderização de texto (com recurso

à tecnologia Signed Distance Field); um conjunto de efeitos built-in (Blur, Glass, etc); um TV Browser

desenvolvido para a criação de animações ‘frame-accurate’; resoluções até 4K; e suporte para ‘video

texture’.

No que diz respeito às facilidades ao desenvolvimento: dispõe de um simulador capaz de ser

executado em Windows, Linux e Mac OSX e de uma API built-in para testing e introspection.

Em paralelo com esta ferramenta é, ainda, disponibilizada uma biblioteca de JavaScript puro

orientada ao desenvolvimento de User Interfaces: Pluto. Esta biblioteca é composta por um conjunto

de classes associadas a widgets disponíveis para serem invocados e reutilizados na construção das

interfaces. Para além disto, Pluto permite ainda, por exemplo, escutar eventos orientados à

agilização da navegação na UI (binding de teclas), gerir os estados dos widgets (foco, selecção,

inatividade), animar elementos ou organizar a forma como os diferentes ecrãs (scenes) se

relacionam.

2.3.1 Protótipo com versão em inglês

Atualmente, o UltraTV suporta dois idiomas: português e inglês. A implementação atual prevê a

possibilidade de introdução de outros idiomas, quando conveniente.

O ficheiro resources.js é responsável pela gestão dos idiomas, tentando carregar os respetivos

ficheiros que contém os objetos (key-value) com as traduções. A decisão do ficheiro a carregar

ocorre mediante a leitura de uma propriedade do objeto DeviceConfig (DeviceConfig.Culture).

Resources.js dispõe de um método que, recebendo uma resourceKey, devolve a respetiva

tradução. Espera-se que todos os elementos textuais da aplicação sejam referenciados sob a forma

de uma key dos ficheiros de tradução (resources/Resources.pt-PT, por exemplo). O idioma carregado

por defeito é aquele que estiver definido em DeviceConfig.js (.Culture), no arranque da box.

Após a resposta da API para a resolução do processo de Bootstrap, o client ser· informado do

idioma correspondente ao perfil carregado, atualizando a propriedade 'Culture' em DeviceConfig.js

Interessa destacar que o idioma é configurado por perfil. Essa configuração não está, de

momento, acessível ao utilizador, mas sim disponível num backoffice de desenvolvimento.

2.3.2 Arquitetura de sistema

A arquitetura do sistema (Figura 22) baseia-se no modelo ‘cliente/servidor’, subdividindo-se em

duas componentes, a componente que corre do lado do cliente denominada de frontend e uma

componente backend, interligando-se por uma ligação à internet.

Deliverable 5.1


Figura 22 - Arquitetura de sistema

Figura 23 - Arquitetura de sistema

Deliverable 5.1


2.3.3 Frontend

O frontend diz respeito à aplicação cliente que foi desenvolvida com recurso a linguagens de

programação com normas abertas, optando-se pelo JavaScript. Parte desta escolha teve influência

na SDK escolhida (Luna) que corre por cima de uma camada de NodeJs e recorre ao JavaScript

como linguagem de implementação predefinida. Para algumas funcionalidades mais avançadas

(animações, listas, grelhas, etc), foi necessário recorrer a uma biblioteca, o Pluto. Esta biblioteca

simplifica e torna mais ágil o desenvolvimento de novas funcionalidades, graças à quantidade de

presets de funcionalidades disponíveis e que podem ser integradas em qualquer parte da aplicação.

Também foram integrados pequenos módulos como, por exemplo, Moment.js, Universal Analytics,

entre outros que satisfazem algumas necessidades pontuais para ultrapassar alguns dos desafios

que foram implementados e que serão explicados ao longo do documento.

2.3.4 Backend

O backend é responsável por alimentar o frontend, fornecendo todos os dados necessários para

cada interface que compõe a aplicação. Estes dados são devolvidos no seguimento de pedidos a

uma web API proprietária do projeto. A web API em questão foi desenvolvida sobre C# e destina-se a

alimentar a aplicação client. Para além da web API, existe ainda uma base de dados (gerida com

recurso a PostgreSQL) e um data collector que alimenta esta base de dados em determinadas

operações, como por exemplo, a recolha do EPG (Electronic Programming Guide). O backend faz

pedidos às API’s que recolhem informação de endpoints diferentes. Apenas alguns desses dados

são armazenados na BD, que estarão disponíveis e que são devolvidos num formato JSON para

poderem ser consumidos pelo client.

2.3.5 Splash screen

Conceito

O ecrã ‘Splash Screen’ é a primeira interface mostrada ao utilizador após o arranque da

aplicação. A existência deste ecrã justifica-se pela necessidade de localizar o utilizador numa

interface enquanto se carregam elementos e se aguardam por respostas de pedidos. O processo de

boot da aplicação pode demorar alguns segundos pelo que interessa manter o utilizador informado.

Interface

Visualmente, o ‘Splash Screen’ é composto por um fundo azul ao qual se sobrepõe uma imagem

com o logo da aplicação e com uma mensagem (‘A televisão do futuro está a chegar’). No canto

inferior direito é mostrado um objeto de loading animado.

Figura 24 - Splash Screen

Deliverable 5.1


Implementação

No que diz respeito às questões técnicas, o processo de boot da aplicação inicia-se através de

um ficheiro main.js que após lido e interpretado lança a aplicação. Neste processo, entre o setup de

eventos Luna e a criação de contextos para renderização de gráficos, é instanciada a view ‘Splash

Screen’ que por sua vez estimula o início do processo de bootstrap.

O processo de bootstrap inicia-se com um pedido a endpoint de uma web API desenvolvida, em

exclusivo, para a aplicação. A resposta ao pedido iniciado com o bootstrap devolve um objeto JSON

que, entre outros dados, informa relativamente os perfis dos utilizadores que utilizam a aplicação.

O ‘Ultra TV’ pretende disponibilizar conteúdos personalizados para cada utilizador, pelo que existe

a necessidade de cada um desses utilizadores estar representado sob a forma de um perfil no

contexto da app. Estes dados, relativos aos perfis, permitem alimentar o menu principal (ervilha)

presente no topo da homescreen, receber os identificadores para cada um destes perfis bem como

um conjunto de tokens para autenticação em serviços com Facebook ou YouTube.

Após uma resposta bem-sucedida por parte deste processo, a aplicação segue para um de dois

ecrãs: um slideshow de imagens que esclarecem como utilizar a aplicação (ao estilo de um tutorial)

durante os 3 primeiros boots da app para cada um dos perfis; ou um homescreen onde consta uma

grelha de conteúdos e um menu principal (ervilha) no topo.

Por último, importa referir que antes de iniciar todo este processo, a aplicação, através de um

pacote de node.JS, pinga um determinado endereço web a fim de garantir que existe conexão à

internet. Caso esta ligação não se verifique, é mostrado um pop-up que. para além, de informar esta

situação, permite reiniciar este processo. Durante todo este processo, e nos restantes em que se

aguardam resposta a pedidos, é mostrada uma animação de loading realizada com recurso à

renderização sucessiva de um conjunto de imagens que permitem animar o widget em questão.

2.3.6 Homescreen

Conceito

O ‘Homescreen’ é a interface de descoberta unificada de conteúdos que combina várias sources

OTT e MEO em categorias, que surge após os dados sobre o perfil de utilizador terem sido

carregados na interface ‘Splashscreen’.

Interface

Esta view apresenta uma grelha de conteúdos temáticos, segmentados por colunas com a

respetiva label de categoria que está sempre presente durante a navegação entre cards, como se

pode observar nas Figura 25 e Figura 26, assim como algumas funcionalidades que permitem

personalizar os conteúdos da grelha, como os perfis. Ao trocar de perfil no widget ‘menu ervilha’ é

possível refrescar os conteúdos sugeridos com base no consumo do utilizador. Também permite

aceder a outras áreas da aplicação, tais como o ‘Meu Conteúdo’, ‘Pesquisa’ de conteúdos e filtrar

colunas por temáticas, consoante a preferência do utilizador.

O widget menu ervilha encontra-se sempre visível no topo da ‘Homescreen’, que para além de

apresentar os ícones das funcionalidades mencionadas, tem a função importante de mostrar ao

utilizador o perfil que está selecionado para não contaminar as recomendações, uma vez que que a

apresentação dos conteúdos na grelha depende da personalização e da visualização de vídeos de

cada perfil.

Deliverable 5.1


Figura 25 – Homescreen

Figura 26 - Silo 'Tv Direto'

Quando se navega na grelha, o card do centro é selecionado e a sua imagem é expandida com

uma breve animação. Após esta animação terminar, surge uma metáfora de picture in picture que se

sobrepõe e faz um tune automático para carregar as primeiras frames do vídeo. Assim que o vídeo

estiver pronto para ser reproduzido é feito o play de imediato. Para além do vídeo, é apresentada

uma camada de informação sobre o conteúdo, como o título, hora de emissão, logótipo do canal, a

classe do conteúdo (‘sugerido’, ‘novidade’, ‘favorito’, etc) e uma barra que mostra o tempo decorrido.

Implementação

Do ponto de vista técnico a ‘Homescreen’ surge no ecrã do utilizador só quando o processo de

bootstrap devolver os perfis daquela box e o último perfil ativo para, de seguida, ser feito um pedido

de conteúdos ao backend com base no perfil selecionado, agrupados por categorias/temáticas.

Enquanto o pedido de conteúdos não é devolvido, são apresentados placeholders de cards com as

respetivas categorias que se preveem estarem disponíveis para consumo. No entanto o utilizador

pode interromper este processo a qualquer momento e mudar de perfil ou aceder a outra área da

aplicação através do ‘menu ervilha’.

Caso não haja uma interação por parte do utilizador, assim que a base de dados devolver o

ficheiro JSON com a informação dos cards, é chamado um método que através de uma lista

horizontal que contém uma lista vertical por cada temática que vier no pedido, assume um aspeto

semelhante ao dos placeholders e seleciona por defeito, o primeiro card da coluna que está ao

centro, expandindo-o para lhe conferir um maior destaque. Quando o card é expandido, é iniciado um

processo para reproduzir o vídeo, que diverge mediante a fonte do conteúdo (stream resolution para

conteúdos MEO, YouTube, Facebook e aplicação Netflix).

Quando o sistema reproduz automaticamente o vídeo, é sobreposto por uma layer de informação

sobre o respetivo card. Apesar deste ‘card selecionado’ servir para mostrar um preview do conteúdo

e respetiva informação num tamanho reduzido, o tempo de visualização conta para o ‘continuar a ver’

(funcionalidade que guarda o momento até ao qual o conteúdo foi visualizado para posterior

Deliverable 5.1


reprodução a partir desse mesmo momento). Se o utilizador quiser visualizar o conteúdo em tela

completa, é possível premir o botão ‘OK’ e seguir para a interface de ‘Fullscreen’.

Uma vez que na ‘homescreen’ só aparecem dez cards de conteúdos ‘sugeridos’ por temática,

caso o utilizador queira ver mais conteúdos da mesma categoria, deve navegar até à posição seis ou

doze da cada coluna para aceder a um card do tipo ‘Ver Mais’, que remete para uma área

semelhante à ‘Homescreen’ com conteúdos relacionados com a temática do ‘card selecionado’ na

‘Homescreen’ (Figura 25). Do ponto de vista técnico, esta view recicla os métodos da ‘Homescreen’ e

reconstrói a grelha de conteúdos com os conteúdos de um novo pedido, com base no perfil de

utilizador e na temática. Para distinguir a view ‘Homescreen’ do silo ‘Ver Mais’, destaca-se o fundo

cor de esmeralda e o título da temática visível por cima das labels de cada coluna.

2.3.7 Fullscreen

Conceito

O ecrã ‘Fullscreen’ é a interface destinada à visualização do conteúdo em ecrã inteiro. Após a

seleção de um conteúdo no ecrã anterior (‘Homescreen’), o utilizador é relocalizado em ‘Fullscreen’.

Para além da possibilidade de consumir o conteúdo selecionado, existem ainda um conjunto de

widgets que permitem interagir com o vídeo bem como obter mais informações relativamente ao

conteúdo em questão.

Interface

Relativamente aos widgets: está disponível um painel de controlo do player de vídeo com as

opções típicas (forward, backward, play, pause); está, também, acessível um menu que permite

recomeçar o conteúdo, tornar o conteúdo ‘favorito’, eliminar o conteúdo da grelha (equivalente a ‘não

gosto’) e aceder a uma outra interface que apresenta informação mais detalhada.

Figura 27 - Controlos player de vídeo

Figura 28 - Menu contextual

Deliverable 5.1


Destaque também para a possibilidade de se aceder a um menu lateral que mostra informações

relativas ao conteúdo em visualização (título, sinopse, canal, etc) e uma lista de três conteúdos

‘relacionados’.

Figura 29 - Menu lateral 'Sugeridos'

Implementação

Do ponto de vista técnico, a escuta feita aos eventos das teclas permite assinalar o momento em

que utilizador seleciona o conteúdo que pretende assistir e, aí, é invocado um método responsável

pela troca das interfaces (views ou scenes). O referido método (changeToView) está disponível na

MainView, a view que se encontra na raíz da stack de views criada e que centraliza métodos e

eventos necessários a todas a views.

A mudança entre as views, gerida através do método referido atrás, é, por sua vez, controlado por

um SceneManager, tipicamente utilizado em ambientes Luna, que contém um conjunto de outros

métodos que permitem criar, gerir e guardar em memória uma stack de scenes, tornando possível a

navegação entre esta mesma stack.

Relativamente ao conteúdo de vídeo reproduzido neste ecrã: trata-se de uma instância do Player

Manager (singleton) que garante a continuação do conteúdo que se encontrava em reprodução na

view anterior. Todas as interações com o vídeo, disponíveis nos diferentes widgets, são geridas

através de um MediaPlayer que permite implementar e gerir o player de vídeo desenvolvido para o

ambiente do Luna.

No que diz respeito à interação com o conteúdo (‘favorito’, ‘não gosto’), esta passa pela

comunicação entre o client e a web API onde, mediante um post, é indicado o identificador do

conteúdo que se pretende considerar ‘favorito’ ou o que se procura remover da grelha (‘não gosto’).

Nos pedidos à web API que se seguem esta comunicação passa a ter impacto, alterando a posição

dos conteúdos ‘favoritos’ na grelha e removendo os conteúdos marcados como ‘não gosto’.

Relativamente ao menu lateral, acessível à direita, que acrescenta mais informação ao conteúdo

visualizado: este surge, em animação, da direita para a esquerda com recurso à tecla direcional

esquerda. Neste momento, é feito um pedido à web API, invocando um endpoint que devolve um

objeto json com informação relativa a conteúdos ‘relacionados’ com aquele que está em visualização,

no momento.

A restante informação que popula o menu em questão, não implica nenhuma comunicação com a

Web API na medida em que essa informação (título, subtítulo e sinopse) provém de um mesmo

objeto pertencente à view anterior e que é injetado aquando da criação da view atual (‘Fullscreen’).

Importa ainda referir que, neste ambiente de ecrã inteiro, é possível navegar entre conteúdos com

recurso à tradicional abordagem ‘P+/P-’. Através das teclas direcionais ‘cima’ e ‘baixo’, é possível

visualizar todos os conteúdos disponíveis na mesma coluna (‘Homescreen’). Tecnicamente, é

recuperado o objeto JSON referente ao card (widget que representa visualmente cada conteúdo no

contexto da aplicação) para o qual se quer navegar. Através do seu identificador e mediante a tecla

premida que dita qual a posição do conteúdo que se pretende recuperar é armazenado e,

Deliverable 5.1


posteriormente, injetado esse mesmo objeto no contexto ‘Fullscreen’. Esta ‘recuperação’ é feita

através da escuta de um evento na ‘Homescreen’ que no momento em que é disparado procede ao

refrescamento dos metadados em ‘Fullscreen’ e estimula a reprodução de vídeo do conteúdo em

questão.

Para além do ‘P+/P-’ é, igualmente, possível, através da mesma abordagem, assistir ao conteúdo

em ‘binge watching’: quando um conteúdo, em ‘Fullscreen’, se aproxima do fim é, novamente,

recuperado o objeto referente ao conteúdo que, visualmente, se encontra, na grelha, na posição

inferior do conteúdo em visualização no momento.

2.3.8 Pesquisa

Conceito

O ‘Search’ é uma interface que permite a pesquisa de conteúdos do MEO, YouTube, Facebook e

Netflix, com recurso a um teclado normal e um teclado preditivo para facilitar a inserção de letras,

ordenando-as de acordo com o maior número de resultados possíveis. Esta view é acedida através

do ‘menu ervilha’ na ‘Homescreen’ ou no silo ‘Ver Mais’.

Interface

No topo do ecrã desta view está presente uma caixa de texto que mostra o resultado de pesquisa.

Imediatamente por baixo surge um rectângulo que atravessa o ecrã horizontalmente, com as teclas

preditivas e um teclado que contém letras, com um botão para alternar números e caracteres

especiais. Caso o utilizador necessite de corrigir o resultado, poderá apagar o último caractere ou

reformular a pesquisa, apagando todo o texto, através dos botões disponíveis à direita. Quando

existem resultados, são apresentados sob a forma cards em listas horizontais que são categorizadas

por source e com indicação do número de resultados encontrados, com base na string de resultado.

Figura 30 - Search

Deliverable 5.1


Figura 31 - Search com resultados

Implementação

Do ponto de vista técnico a view pesquisa integra a caixa de texto de pesquisa com um widget

para o teclado preditivo, assim como widgets disponíveis através da biblioteca Pluto, para construir

as listas horizontais que contêm os cards de conteúdos. Para além disso, esta view contém os

métodos necessários para fazer pedidos à API, com a string da caixa de pesquisa e de atualizar as

listas de conteúdo.

O widget do teclado é responsável por devolver a letra selecionada pelo utilizador, pela

navegação dos itens do teclado e também implementa as listas horizontais do Pluto para inserir os

widgets dos botões obtidos através de um ficheiro JSON local. Cada botão tem uma propriedade

denominada ‘action’, que mediante o respetivo valor, permite que o teclado intérprete se o botão

premido é para adicionar uma letra, apagar, limpar, ou trocar de teclado. Quando o utilizador forma

uma string com o mínimo de 2 letras é feito um pedido para apresentar os resultados. Assim que o

cliente recebe uma resposta através de um JSON que contém os resultados e devolve também as

sugestões das letras mais prováveis de serem escolhidas pelo utilizador, para serem integradas no

teclado preditivo, ordenadas com base na quantidade de conteúdos existentes com aquelas letras.

Quando a aplicação recebe os resultados da pesquisa e constrói as listas horizontais constituídas

com cards, que têm uma layer de informação sobreposta na imagem do card. Para além disso, se o

utilizador já viu uma parte do conteúdo, o card é coberto com um gradiente esverdeado, consoante a

percentagem de conteúdo visto. O utilizador pode selecionar um dos cards para ver o conteúdo em

‘Fullscreen’. Quando não quiser continuar a ver o conteúdo selecionado em 'Fullscreen’ e premir o

botão back do comando, volta para o ecrã de ‘Search’ com o último card selecionado.

2.3.9 Filtros

Conceito

A opção ‘Filtros’, disponível através do menu ‘ervilha’ no ecrã ‘Homescreen’, permite esconder

colunas e, neste sentido, filtrar o conteúdo oferecido. É possível, através dos ‘Filtros’, esconder todas

as colunas à exceção da coluna relativa à ‘Tv Direto’ e às sugestões da aplicação (‘Sugestão TV’ e

‘Sugestão Web’).

Interface

Esta opção materializa-se num pop-up animado, surgindo do fundo do ecrã até ao centro,

apresentando uma lista (ListWidget pertencendo ao Pluto) com os headers/títulos das colunas. Junto

Deliverable 5.1


aos títulos das colunas surgem as respetivas checkboxes que permitem a sua seleção, bem como,

no fundo da lista, a opção ‘Todas’ que permite a seleção de todos os títulos.

Figura 32 - Filtros

Implementação

Do ponto de vista técnico, a funcionalidade ‘Filtros’ é composta por uma view que se sobrepõe,

visualmente, à ‘Homescreen’ e que insere um widget: FiltersPopUp. O construtor deste widget cria o

container onde a lista se insere e instancia, ainda, um novo widget: FiltersWidget.

Este último widget trata, por sua vez, de invocar o endpoint da WebAPI responsável por devolver

os títulos das colunas que se encontram ativas (não filtradas) para gerir o estado das checkboxes

que acompanham os títulos das colunas. No contexto dos pedidos feitos à Web API são utilizadas

promises. Neste seguimento, no momento em que a promise em questão é resolvida, é invocado um

método que cria as listas onde, posteriormente, são introduzidos os títulos e as respetivas

checkboxes que compõe um outro widget: FiltersButtonWidget. Este último, ‘desenha’ os títulos e as

checkboxes e declara um método responsável por atualizar o estado das checkboxes

(updateValue()).

Logicamente que, para além de um primeiro pedido à Web API (get), será necessária uma

segunda interação (post) com as colunas a filtrar. No momento em que o pop-up é fechado é lançado

um evento que, no momento em que é escutado na FiltersView, informa o backend, através de um

post, quais as colunas a filtrar (acrescentando-as a uma black list). Para além da informação relativa

às colunas é, também, indicado o identificador do perfil ativo no momento. A próxima utilização dos

‘Filtros’ iniciar-se-á com um pedido para obter as colunas ativas (não filtradas) que aparecerão sem

seleção, por defeito, ao passo que as restantes encontrar-se-ão selecionadas, informando que,

naquele momento, o utilizador ativo filtrou essas mesmas colunas.

2.3.10 O meu conteúdo

Conceito

O ‘Meu Conteúdo’ é uma área da aplicação que apresenta conteúdos que o utilizador já tenha

interagido através das outras áreas da aplicação. Estão disponíveis, nesta área, conteúdos do tipo

‘Favorito’, ‘Continuar a Ver’ ou Gravações. De futuro, poderá ainda ser possível aceder a uma store

de aplicações ou ao videoclube MEO. O layout que é apresentado nesta interface assemelha-se à

Homepage, conferindo consistência na interação e acesso a conteúdos.

Deliverable 5.1


interface

Os cards que são apresentados na coluna ‘Favoritos’ dizem respeito aos conteúdos que foram

adicionados aos ‘favoritos’ pelo utilizador. Desta forma, tem um espaço sempre disponível e que se

destina apenas para apresentar todos os conteúdos que ‘gosta’. Na coluna ‘Continuar a ver’ estão

disponíveis os conteúdos com pelo menos dez por cento de visualização e que não tenham sido

vistos até ao fim. No entanto, se o utilizador vir um conteúdo dessa coluna até ao fim, deixa de fazer

sentido pertencer a esta coluna e, portanto, será removido.

Figura 33 - Favoritos

Figura 34 - 'Continuar a ver'

Implementação

Do ponto de vista técnico, este view recicla os métodos da ‘Homepage’ e constrói as colunas com

os conteúdos que a API retorna, com base na utilização que o utilizador faz do sistema.

2.3.11 Mais info

Conceito

A opção ‘Mais Info’, disponível no menu do ecrã ‘Fullscreen’, permite aceder a um conjunto de

informação mais detalhada relativa ao conteúdo que se encontra em visualização. É pretendido que

este ecrã acrescente profundidade à informação disponível no menu lateral acessível em Fullscreen.

Pela sua largura reduzida na interface, este menu não apresenta espaço suficiente para oferecer

grande quantidade de informação, pelo que se justifica a existência de um ecrã dedicado à

disponibilização de informação de pormenor.

Deliverable 5.1


Interface

O ecrã ‘Mais Info’ oferece a sinopse completa do conteúdo, o horário, o género/t ipo, a duração, o

elenco (para conteúdos onde esta informação faz sentido) e, ainda, uma lista de conteúdos de

‘Relacionados’.

Figura 35 - 'Mais info'

Implementação

Do ponto de vista técnico, é invocado um endpoint da Web API (FullScreenMoreInfo) que, na

resposta, devolve um objeto JSON com as strings necessárias para popular campos informativos

(títulos, sinopse, elenco, etc.), bem como um array de conteúdos sugeridos sob a forma de card.

Os conteúdos ‘Relacionados’, posicionados no fundo do ecrã, estão organizados numa lista

horizontal (com recurso ao ListWidget) composta por cards que permitem explorar outros conteúdos

relacionados com o que se encontra em visualização. Esta lista, à semelhança do ecrã em questão,

acrescenta profundidade aos três conteúdos recomendados possíveis de serem consultados no

menu lateral disponível no ecrã Fullscreen.

Tecnicamente, a seleção de um card ‘Recomendado’ invoca um método (changeToView) que

recebe como parâmetro de entrada o objeto JSON referente ao card do conteúdo em consideração.

Posto isto, instancia um ‘novo fullscreen’ e inicia, neste ambiente, a reprodução do conteúdo

selecionado. Procede, ainda, à atualização dos metadados que compõem os widgets existentes na

view em questão.

2.3.12 Outros aspetos relevantes relativos à implementação técnica

Widget

No contexto da aplicação, um ‘card’ refere-se ao elemento que representa um conteúdo (OTT ou

web). Visualmente, trata-se de um container rectangular que apresenta metadados, tecnicamente

recebidos através de um parâmetro no construtor do widget, referentes ao conteúdo em questão. Os

metadados presentes no card variam consoante o contexto onde este widget se insere. Os

metadados variam entre: capa do conteúdo, título, subtítulo, barra de progresso, data de publicação

ou logótipo da fonte/canal.

A grelha de conteúdos, que compõe a ‘Homescreen’, é composta por diversos cards deste tipo:

maioritariamente cards que apenas apresentam as capas dos conteúdos e, ao centro, um card em

foco de grandes dimensões que reproduz vídeo e ao qual se sobrepõem a totalidade dos metadados

anteriormente referidos.

Já em outros contextos da aplicação são inseridos widgets desta mesma natureza, mas com

diferenças gráficas e de interface para se adaptar às especificidades de cada um dos ecrãs. Por

Deliverable 5.1


exemplo, em Fullscreen, os conteúdos ‘Recomendados’ são apresentados sob a forma de um card

de dimensões reduzidas mostrando apenas título, subtítulo, data de publicação e logo do canal/fonte.

Content.js e RequestManager.js

Estes são os dois ficheiros que contêm as instruções relativas aos pedidos à web API proprietária

do projeto e às APIs do Facebook e do YouTube para efeitos de autenticação nestes serviços.

No ficheiro Content.js estão disponíveis os dados necessários aos pedidos: URL’s, objetos a

serem passados no body dos pedidos bem como toda a lógica necessária para invocar os métodos

que concretizam os pedidos centralizados no RequestManager.js. No que diz respeito ao

RequestManager.js importa referir que este concretiza os pedidos e, com base numa promise,

executa as chamadas às APIs (performCall()) de acordo com os verbos e com os parâmetros

necessários a serem incluídos na chamada. Nos pedidos à web API proprietária do projeto é, ainda,

feita uma verificação prévia relativa à validação de um token de autenticação necessário aos pedidos

em questão.

PlayerManager.js

O PlayerManager é responsável pela resolução de URL’s e streams consoante o seu tipo (Live,

VOD, YouTube, Facebook). Este processo, que difere consoante o tipo de conteúdo, é necessário

para a obtenção de um URL cujo player de vídeo do Luna consiga interpretar devidamente. Para o

caso específico dos conteúdos Netflix este processo é diferente na medida em que o client apenas

dispara um intent a fim de lançar a aplicação proprietária da Netflix. Todo o consumo de conteúdos

deste tipo é feito num ambiente externo ao UltraTV: a app Netflix.

O PlayerManager é, ainda, responsável pelo controlo de sessões (SessionTearDown) em

conteúdos VOD e Live a fim de ser possível fazer a gestão das streams a serem consumidas.

Importa, também, referir que o PlayerManager se encarrega de controlar o bookmarking dos

conteúdos a fim de ser possível a utilização da funcionalidade ‘Continuar a ver’ onde o utilizador

pode retomar a visualização do conteúdo no momento em que se encontrava anteriormente.

SceneManager.js

O SceneManager é responsável pela troca de scenes (cenas). No contexto Luna, cenas são, na

prática, um ecrã/interface. Em ambiente de desenvolvimento as scenes assumiram a designação

‘views’.

A navegação dentro da aplicação é feita através da troca entre ecrãs simulando a relocalização

do utilizador num novo ambiente. Esta troca de ecrãs é feita através da gestão da stack de scenes

que vai sendo criada cada vez que se instancia uma nova cena. O SceneManager.js centraliza a

gestão destas cenas procedendo, sempre que necessário, a um ‘Scene Hide’ e, de seguida, a um

‘Push Scene’ forçando a cena ‘pushed’ a ocupar o topo da stack de cenas, fazendo com que esta

seja a que está a ser mostrada na aplicação.

Autenticação em serviços externos: Facebook e YouTube

A fim de ser possível recolher conteúdos personalizados para cada utilizador é necessária uma

autenticação nos serviços das plataformas em questão. Neste seguimento, o client mostra, numa

primeira fase, a cada utilizador, um ecrã com um código. Para além deste código, mostra ainda um

URL que deverá ser visitado para introduzir esse mesmo código. A introdução do código atribui as

devidas permissões ao UltraTV para proceder à recolha das páginas que o utilizador ‘gostou’ ou às

quais está subscrito. Posto isto, é possível ao backend colecionar os vídeos dessas mesmas páginas

Deliverable 5.1


e disponibilizar na aplicação conteúdos provenientes do Facebook ou do YouTube personalizados

para o utilizador.

Visualmente, estes ecrãs são compostos por um fundo branco, com os logo das plataformas e

com um texto que esclarece o procedimento esperado pelo utilizador neste processo.

Tecnicamente, é feito um primeiro pedido à web APIs destes serviços a fim de receber, entre

outros dados, o código a ser exibido ao utilizador. De seguida, espera-se que a aplicação efetue um

pooling às APIs para averiguar em que momento o utilizador introduz o código que lhe foi mostrado.

Quando a resposta a esse pooling é acompanhada por um status code 200 significa que o utilizador

introduziu, com sucesso, o código no URL que lhe foi disponibilizado.

Para além deste status code, é recebido um objeto com um token que permitirá ao backend iniciar

o seu processo de recolha de vídeos nos serviços do Facebook. A tarefa do client termina, neste

sentido, com um post do token em questão na web API proprietária do projeto para libertar a ação do

backend na recolha dos conteúdos.

Recolha de metadados

De modo a acompanhar/avaliar a utilização de sistemas televisivos pelos consumidores ocorre

através da monitoração dos hábitos e consumos audiovisuais a partir de serviços multi-plataforma de

tracking assíncrono, como é o caso do Google Analytics. Desta forma, fez-se um mapeando de todas

as secções e eventos da aplicação através da integração de um módulo que integra o google

analytics para aplicações que não corram através de um browser, como o Universal Analytics. Para

além de uma recolha geral, como a ‘HomeScreen’ sugere conteúdos com base no que os utilizadores

visualizaram, a aplicação necessita de registar todos os conteúdos que são vistos pelo utilizador e a

respectiva duração de visualização. Para contemplar este requisito, foi desenvolvida a API

‘AssetWatched’, que regista todos os conteúdos vistos por cada utilizador, para que mais tarde, a

‘HomeScreen’ possa obter conteúdos com base nos hábitos de consumo de cada utilizador.

Google Analytics

O Analytics é um serviço da Google, que faz o registo de todo o tráfego de um site/aplicação, por

utilizador (denominado por visitante). Este serviço é geralmente utilizado para aumentar o lucro de

um site/aplicação através do mapeamento do percurso de cada utilizador, identificando potenciais

problemas de performance, através de técnicas como funnel analysis (análise de funil), de onde vêm

os visitantes, quanto tempo permanecem e qual é a sua localização geográfica. Para além disso,

oferece ferramentas mais avançadas, que permitem a gestão de um negócio através de e-commerce,

apresentando os lucros, transações, entre outras métricas. Não obstante, este serviço também pode

ser utilizado apenas pela componente flexível de asynchronous cross-platform tracking, seja para

observar os dados em tempo real, seja para fazer uma análise posterior, tanto ao nível do percurso

do utilizador para encontrar possíveis problemas de usabilidade, como para analisar as áreas da

aplicação com maior tráfego. Neste cenário, o analytics permite a personalização de variáveis que

podem ser métricas ou dimensões, para que se possa segmentar a informação por blocos que se

considerem importantes analisar.

No que refere à utilização do Google Analytics no contexto televisivo, a ferramenta permite gerir o

período de consumo por sessões, permitindo observar o tempo médio de sessão, mapear todos os

dados da aplicação em tempo real que tem um peso muito importante no contexto televisivo (“Google

Analytics helps TV App Agency efficiently produce high-quality data for their connected TV clients”

2012) e permite a monitorização de reports personalizados, assim como a parametrização de

variáveis métricas, facilitando a consulta de dados relevantes e a possibilidade de filtrar toda essa

informação através de dimensões. Essas características tornam o GA um serviço viável para

Deliverable 5.1


entender melhor os hábitos de consumo audiovisuais pelos utilizadores graças às funcionalidades de

personalização de conteúdo, pois permitem fazer uma análise geral e pormenorizada dos dados

recolhidos e avaliar problemas ou inconsistências mais rapidamente.

Por este serviço ser baseado em javascript, poderá ser bloqueado por extensões e programas

que filtram publicidade, assim como aplicações Android e iOS que sejam utilizadas com a mesma

finalidade e a localização geográfica também pode ser mascarada. Não obstante, esta limitação é

considerada pequena, uma vez que é afetada por um grupo pequeno de visitantes. Outro problema

recorrente é que, como o analytics baseia-se em cookies, se estes forem removidos, não é possível

recolher dados, resultando em perda de informação que previne por exemplo, o uso eficaz da

publicidade para um determinado visitante. Uma das limitações mais importante é a forma como o

analytics coleta informação, denominada por sampling (amostragem) para a criação dos reports (com

um limite de 500,000 reports), que permitem ver o fluxo de informação. Apesar de estarem

escrutinadas as margens de erro para a métrica das visitas, não existe nenhuma outra informação

relativa aos restantes reports, podendo existir grandes margens de erro para pequenos segmentos

de informação.

Universal Analytics

Como o Analytics está otimizado para ser integrado em sites web através de scripts, a sua

integração com a framework Luna não tinha uma implementação direta. Uma vez que a base do

Luna é Node.js, foi implementado um módulo de Analytics denominado por Universal Analytics como

uma classe singleton na aplicação, para que os dados Inicializados sejam persistentes enquanto

existir uma sessão na aplicação. No arranque (fase de bootstrap) da aplicação, depois de receber um

pedido da API com os dados dos Id’s dos utilizadores e qual o utilizador que está selecionado é

inicializada a classe Analytics com os parâmetros base (User ID, Visitor). Nesse pedido é devolvida

uma flag que indica se o sistema está a utilizar um GUID de developer ou produção. Mediante essa

flag, os dados serão registados no respectiva conta de Analytics - developer ou produção - para que

os dados de produção não sejam comprometidos pelos testes de desenvolvimento. De seguida

instancia-se um visitante, com um ID de visitante personalizado (“USERID_” seguido do ID de

backend), para que seja possível fazer o tracking de cada participante do field-trial por box.

No que diz respeito à aplicação, foram mapeados todos os ecrãs e eventos que se integravam

nos objetivos do que se pretendia investigar, como o tempo de pesquisa versus o tempo de

visualização de um conteúdo, ecrãs visitados pelo utilizador, análise e avaliação de usabilidade,

entre outros.

Para que o registo de ecrãs e eventos não se repetissem ao longo do código da aplicação e

adicionar código que fosse redundante nos scripts da aplicação, criaram-se métodos no singleton

Analytics que cuidam de toda a lógica associada com a especificidade de cada tipo de registo, de

modo que seja apenas necessário fazer uma chamada de cada método e satisfazer os respetivos

parâmetros com os dados necessários. Todos os métodos específicos para tipo de registo, apontam

a informação do pedido para um único método, cujo seu objetivo é garantir que os dados estão no

formato pretendido e caso não se verifiquem incongruências com a metainformação, são enviados

para o Analytics.

AssetWatched

A API AssetWatched recolhe dados de vídeos visualizados pelo utilizador, para alimentar o motor

de sugestão de conteúdos com base no consumo de cada perfil. Esta API processa e analisa os

dados recolhidos e define quais os conteúdos recomendados para cada utilizador. Quando a

aplicação do UltraTV faz um pedido para gerar os conteúdos da HomeScreen, o backend por sua

vez, faz um pedido de sugeridos ao AssetWatched e devolve um JSON para o frontend com os

conteúdos personalizados para cada utilizador.

Deliverable 5.1


Assim como no Analytics, foi necessário separar o código necessário para o registo dos

conteúdos numa classe singleton porque, apesar do pedido que é feito ser do tipo POST, este

sistema requer que seja recolhida muita informação sobre o vídeo que está a ser consumido e

também necessita que alguns dados sejam transformados para valores padrão que são esperados

do lado da API. Isto devesse ao facto que que este serviço recebe e analisa informação da aplicação

UltraTV e do sistema televisivo MEO. O método de inicialização é semelhante ao do analytics,

através de uma classe singleton, que instância as variáveis de sessão. No entanto, apesar de ser

necessário informar a API com o utilizador que visualizou o conteúdo, não é necessário inicializá-lo

como no analytics, uma vez que cada pedido contém um parâmetro utilizador que está loggado na

aplicação e todos os dados são enviados no body do pedido.

Deliverable 5.1


Conclusão Este documento apresenta o processo de sistematização de guidelines do sistema em STB

UltraTV, com base nas recomendações previamente recolhidas no milestone 5.1 e após a iteração e

avaliação de várias versões que culminaram no protótipo final, validado através de um field trial.

Deliverable 5.1


Referências

Abreu, L. (2014, Maio 14). Why and How to Avoid Hamburger Menus. Retirado de

https://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/.

Android, (2017). Designing for Android TV. Retirado de

https://developer.android.com/design/tv/index.html

Apple (2017). Animation. Retirado de https://developer.apple.com/ios/human-interface-

guidelines/visual-design/animation/.

Apple, (2017). Human Interface Guidelines. Retirado de https://developer.apple.com/tvos/human-

interface-guidelines/visual-design.

Apple, (2017). tvOS Design Themes. Retirado de https://developer.apple.com/tvos/human-

interface-guidelines/.

Archer, J. (2017). The hamburger menu doesn't work. Retirado de

http://jamesarcher.me/hamburger-menu.

Babich, N. (2016, Março 2). Responsive Design Best Practices. Retirado de

https://uxplanet.org/responsive-design-best-practices-c6d3f5fd163b.

Cao, J. (2017, Maio 3). The New Rules for Scrolling in Web Design. Retirado de

https://designmodo.com/scrolling-web-design/.

Chapman, C. (2010, Janeiro 28). Color Theory for Designers, Part 1: The Meaning of Color.

Retirado de https://www.smashingmagazine.com/2010/01/color-theory-for-designers-part-1-the-

meaning-of-color.

Chorianopoulos, K. User Interface Design Principles for Interactive Television Applications. Taylor

& Francis Group. Thuringia. Germany (2017)

Ericsson Consumer and Industry Insight Report: TV and Media 2016. The evolving role of TV and

media in consumers' everyday lives. Retirado de https://www.ericsson.com/assets/local/networked-

society/consumerlab/reports/tv-and-media-2016.pdf (2016).

Girard, J. (2015, Outubro 19). 10 rules of best practice for responsive design. Retirado de

https://thenextweb.com/dd/2015/10/19/10-rules-of-best-practice-for-responsive-design/.

Google (2017). Design Principles. Retirado de https://www.google.com/design/spec-tv/design-

principles/creative-vision.html.

Google (2017). Material Design. Retirado de http://material.io/guidelines/.

Google (2017). Responsive UI. Retirado de https://material.io/guidelines/layout/responsive-ui.html

Head, V. (2017, Junho 22). A beginner's guide to designing interface animations. Retirado de

http://www.creativebloq.com/web-design/beginners-guide-designing-interface-animations-61617793.

Kennedy, Erik (2017, Janeiro 18). Color in UI Design: A (Practical) Framework. Retirado de

https://medium.com/@erikdkennedy/color-in-ui-design-a-practical-framework-e18cacd97f9e.

Kollin, Z. (2016, Novembro 3). Hamburger menu alternatives for mobile navigation. Retirado de

https://medium.com/@kollinz/hamburger-menu-alternatives-for-mobile-navigation-a3a3beb555b8.

Muzli (2016, Março 31). Icons Animation Inspiration. Retirado de https://medium.muz.li/icons-

animation-inspiration-73a907732bca.

Deliverable 5.1


Nguyen, D. (2015, Maio 11). Guidelines for Animation Timing. Retirado de

http://blog.percolatestudio.com/design/animation-timing-guidelines/.

Nielsen Company. The Battle for Eye Space in a TV-Everywhere World. (2017). Retirado de

http://www.nielsen.com/content/dam/corporate/Italy/reports/2015/Nielsen%20Global%20Digital%20La

ndscape%20Report%20March%202015.pdf(2015).

Rose, A. (2014, Abril 8). UX Designers: Side drawer navigation could be costing you half your user

engagement. Retirado de http://thenextweb.com/dd/2014/04/08/ux-designers-side-drawer-navigation-

costing-half-user-engagement.

Selvaraj, S. (2013, Novembro 22). Animation Principles in UI Design: Understanding Easing.

Retirado de https://medium.com/motion-in-interaction/animation-principles-in-ui-design-

understanding-easing-bea05243fe3.

Viljamis Design (2016, Junho 21). Typography for User Interfaces. Retirado de

https://viljamis.com/2016/typography-for-user-interfaces/

Whited, B. (2013, Março 28). Setting Type for User Interfaces. Retirado de

https://blog.typekit.com/2013/03/28/setting-type-for-user-interfaces/.

Wroblewski, L. (2012, Março 14). Multi-Device Layout Patterns. Retirado de

http://www.lukew.com/ff/entry.asp?1514

Ultra TV Deliverable · • Barra de duração e percentagem visualizada • Data e hora de...

Documents

Transcript of Ultra TV Deliverable · • Barra de duração e percentagem visualizada • Data e hora de...