Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
Guidelines de Design Gráfico e de Interação da UI 5
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)
Guidelines de Design Gráfico e de Interação da UI 7
Í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
Guidelines de Design Gráfico e de Interação da UI 9
Í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
Guidelines de Design Gráfico e de Interação da UI 11
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
12 Guidelines de Design Gráfico e de Interação da UI
• 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 de Design Gráfico e de Interação da UI 13
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
14 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 15
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
16 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 17
• "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
18 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 19
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
20 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 21
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
22 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 23
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.
Deliverable 5.1
24 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 25
Figura 22 - Arquitetura de sistema
Figura 23 - Arquitetura de sistema
Deliverable 5.1
26 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 27
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
28 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 29
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
30 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 31
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
32 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 33
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
34 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 35
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
36 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 37
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
38 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 39
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
40 Guidelines de Design Gráfico e de Interação da UI
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
Guidelines de Design Gráfico e de Interação da UI 41
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
42 Guidelines de Design Gráfico e de Interação da UI
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