Desenvolvimento de Aplicações Declarativas para TV Digital Interativa

Transcrição

1 Capítulo 1 Desenvolvimento de Aplicações Declarativas para TV Digital Interativa Carlos de Salles Soares Neto, Simone Diniz Junqueira Barbosa, Luiz Fernando Gomes Soares, Rogério Ferreira Rodrigues Abstract This course addresses the declarative authoring of programs for the Interactive Digital TV. The course presents the reference models for Digital TV and the main application types. The development of NCL (Nested Context Language) applications is described and illustrated by examples, including their supporting mechanisms for media synchronization and their tools for the nonlinear editing of programs. The course also presents some basic concepts of usability and their applications to the design of interactive audio-visual programs. Resumo Este mini-curso é voltado para a autoria declarativa de programas para TV Digital Interativa. O mini-curso apresenta os modelos de referência para TV Digital e os principais tipos de aplicações. O desenvolvimento de aplicações com base em NCL (Nested Context Language) é descrito e ilustrado com exemplos, o que inclui seus mecanismos de suporte para o sincronismo de mídias e ferramentas para edição de programas não-lineares. O mini-curso também objetiva apresentar alguns conceitos básicos de usabilidade e suas aplicações para o design de programas audiovisuais interativos Introdução A mudança da TV Analógica para a TV Digital não significa apenas uma melhora significativa na qualidade da imagem e do som. Com a TV Digital, problemas decorrentes de ruídos ou multipercurso de sinal não são mais graves. Enquanto houver sinal mantém-se a mesma qualidade na reprodução do conteúdo. Outro aspecto importante é a tendência natural ao surgimento de uma vasta gama de novos serviços na

2 TV Digital, como a oferta de guias eletrônicos de programas, a distribuição de jogos de computador, o controle de acesso e a proteção de conteúdo (criptografia). Assim como ocorreu na área de telecomunicações há alguns anos, o foco para a definição de um novo sistema de TV Digital não parece ser apenas o de permitir uma maior interoperabilidade de aparelhos. Outro importante desafio desse novo modelo de TV é a adoção de padrões que permitam a construção rápida, fácil, eficiente e livre de erros de novas aplicações interativas. A dificuldade em fornecer tais serviços parece evidente: apesar da expectativa de haver um amplo número de equipamentos diferentes, é necessário um alto grau de interoperabilidade para que o autor de programas interativos crie um único documento para ser reproduzido em qualquer plataforma de recepção. As novas funcionalidades da TV Digital interativa podem ser resumidas como agregar capacidade computacional à TV. Como há um grande legado de TVs analógicas, uma solução simples para oferecer esses novos serviços é utilizar junto à TV um pequeno computador capaz de tratar corretamente o sinal de radiodifusão, decodificá-lo e exibir de forma consistente a programação de TV, as aplicações e os serviços avançados. Esse computador é chamado de terminal de acesso (ou set-top box). Num futuro próximo, a tendência por uma convergência é natural, de forma que a TV traga embutido esse terminal de acesso e mais, que outros dispositivos de exibição possam ser utilizados como celulares, PDAs, etc. Há tipicamente três camadas de software atuando em um terminal de acesso: os serviços, programas e aplicações (no nível mais alto); o middleware; e o sistema operacional. O sistema operacional atua como uma camada de abstração para facilitar a implementação de programas, tornando-os independentes do hardware sobre o qual eles executam. O middleware é uma camada que atua sobre o sistema operacional e cuja função é oferecer aos diferentes serviços, programas e aplicações, por meio de uma API bem definida, o conceito de uma máquina abstrata sobre a qual se tem uma visão única dos diferentes tipos de terminais de acesso. Ao definir o middleware para um terminal de acesso, os padrões oferecem o suporte para dois tipos de aplicações: as imperativas e as declarativas. Em geral, aplicações onde o sincronismo e adaptabilidade exercem papéis preponderantes são mais fáceis de serem especificadas usando uma linguagem declarativa orientada a esse tipo de foco. Porém, quando a exigência de sincronismo ou adaptabilidade é apenas eventual, o melhor suporte é dado por uma linguagem imperativa de propósito geral. O conjunto de serviços que dão suporte ao desenvolvimento de aplicações imperativas tem como objetivo definir uma máquina abstrata única que é chamada de máquina de execução. Por sua vez, os mecanismos para o suporte a aplicações declarativas compõem a máquina de apresentação. Alguns exemplos de máquinas de apresentação são o ACAP-X [ATSC 2005], DVB-HTML [ETSI 2005], BML [ARIB 2004] e o Ginga-NCL. Este mini-curso é voltado especificamente para a autoria declarativa de programas interativos para TV Digital Interativa fazendo uso da máquina de apresentação Ginga-NCL.

3 1.2. Principais tipos de aplicação As aplicações de TV Digital Interativa podem estar ou não semanticamente associadas ao conteúdo do áudio ou vídeo principal. Adicionalmente, elas podem definir ou não relações de sincronismo entre objetos de mídia que a compõem, entre eles o conteúdo principal (vídeo e áudio). Uma aplicação de correio eletrônico, por exemplo, está sempre disponível e não possui relação semântica com o conteúdo do programa televisivo exibido. Por outro lado, uma aplicação que calcula o nível de estresse em um programa de saúde, por exemplo, poderia estar disponível durante toda sua exibição. É conveniente notar que, mesmo não havendo relações de sincronismo dessas aplicações com o áudio e vídeo principal, tais aplicações podem ser compostas de objetos que mantêm relações de sincronismo entre si. Ainda um terceiro tipo de aplicação é composto por aplicações em que existe não só uma relação semântica entre seus objetos de mídia e o áudio e vídeo principal do programa televisivo, mas também uma relação de sincronismo. Esse é exatamente o caso dos chamados programas não-lineares. O termo não-linear vem em contraposição à forma seqüencial linear que caracteriza os programas para a TV analógica. Nesses últimos, existe um e apenas um caminho, seqüencial, de exibição. Ao contrário, os programas não-lineares são compostos de múltiplas cadeias de exibição, algumas exibidas em paralelo e outras como alternativas (ou seja, ou uma cadeia ou a outra) que dependem da escolha do usuário, do terminal onde o programa será exibido, da região onde o telespectador está inserido etc. O exemplo mais simples de um programa não-linear é aquele onde, em um dado instante de exibição, o usuário telespectador pode escolher entre formas alternativas de sua continuação. Note assim que o programa deixa de poder ser representado por uma linha de tempo e passa a ter um fluxo de exibição que pode ser especificado por um grafo. Na grande maioria dos casos, a linguagem declarativa tende a ser a preferencial no desenvolvimento dos programas não-lineares. Mais ainda, como em programas nãolineares o sincronismo intermídia sem a interação do usuário deve ser tão ou mais importante que a interatividade, o sincronismo de mídias em sua forma mais ampla, e não a interatividade, deve ser o foco das linguagens declarativas, como é o caso da linguagem NCL, proposta para o SBTVD. Um outro aspecto importante para as aplicações é a adaptabilidade. Ao agregar capacidade computacional à TV, torna-se possível fazer com que o terminal de acesso adapte o conteúdo de acordo com informações de contexto referentes às preferências ou localização do usuário, ou ainda à disponibilidade atual do terminal de acesso (capacidade de processamento, memória disponível etc). A adaptação pode não envolver apenas o conteúdo de cada objeto de mídia individualmente mas também a própria forma de apresentação. NCL provê suporte a ambos os tipos de adaptação. O suporte a múltiplos dispositivos de exibição é também uma característica importante no suporte à interatividade em um sistema de TV digital. Através de múltiplos dispositivos de exibição será possível, por exemplo, que a interação de um usuário com o programa de TV traga novos objetos a serem exibidos em seu dispositivo particular de interação, sem que apareçam na tela da TV, não atrapalhando, assim, uma

4 audiência coletiva. O suporte a múltiplos dispositivos de exibição é outra característica importante da linguagem NCL. Independente de a autoria ser feita de forma declarativa ou imperativa, é necessário oferecer o suporte à produção de programas não-lineares ao vivo. Geralmente, a autoria e a exibição de documentos multimídia (como os programas da TV Digital interativa) ocorrem em fases distintas. Em um evento ao vivo, no entanto, é necessário que a autoria do documento ocorra ao mesmo tempo em que é feita a exibição. A máquina de apresentação Ginga-NCL oferece suporte à exibição e edição de programas não-lineares ao vivo. Para isso ela é capaz de receber, via carrossel de dados do padrão DSM-CC [ISO 1998], a especificação de um programa NCL, e controlar a exibição sincronizada de seus objetos. Através do mecanismo de sincronização baseado em elos da NCL, e de um protocolo de sinalização baseado em eventos DSM-CC, foi possível construir um modelo de edição de programas de TV em paralelo com suas exibições [Moreno et al. 2005]. Comandos de edição foram definidos, permitindo que o middleware seja notificado para adicionar ou remover uma entidade NCL (objeto de mídia, âncora, elo, contexto etc.) em tempo de exibição. Esses comandos são enviados através de eventos de sincronização (stream events) oferecidos pelo padrão DSM-CC. A máquina de apresentação Ginga-NCL efetua a operação e recalcula as suas estruturas de dados de execução para que a mudança surta o efeito na exibição do programa. Incluir e retirar objetos e elos de contextos são operações triviais em documentos NCL, uma vez que não implicam mudanças na estrutura do documento. Cabe ressaltar que a inclusão de tal facilidade em modelos de sincronismo baseados em composições seria muito difícil Modelo de Contextos Aninhados (NCM) NCL (Nested Context Language) é uma linguagem de autoria de documentos multimídia baseada no NCM. O NCM (Nested Context Model, Modelo de Contextos Aninhados) utiliza os conceitos de nós (nodes) e elos (links) comumente aplicados em documentos hipermídia (Figura 1.1a). (a) Figura 1.1. Nós e elos (a) num hipertexto comum e (b) com nós de composição (contextos). No NCM, os grafos podem ser aninhados, permitindo segmentar e estruturar o documento hipermídia conforme necessário ou desejado. Isto é feito através de nós de composição, que são nós compostos de grafos NCM (Figura 1.1b). Um nó de composição também é chamado de contexto. (b)

5 Assim, em NCM, um node (nó) pode ser de dois tipos: nó de conteúdo ou de mídia (content node ou media node): associado a um elemento de mídia como vídeo, áudio, imagem, texto, aplicação etc.; ou nó de composição ou contexto (composite node ou context). No caso da Figura 1.1b, capítulo 1 e capítulo 2 são contextos (nós de composição), enquanto cada seção é um nó de conteúdo. Para auxiliar a construção de documentos hipermídia seguindo o modelo NCM, foi desenvolvida a linguagem NCL, que será utilizada por todo este documento na elaboração de exemplos de documentos hipermídia. Os elementos da linguagem serão introduzidos progressivamente, com base em exemplos. Os exemplos serão baseados na versão atual da máquina de apresentação Ginga-NCL, que interpreta um documento NCL e apresenta o programa audiovisual interativo nele representado. As seções seguintes apresentam uma introdução básica sobre vários elementos do modelo NCM e como os mesmos são expressos por meio de NCL. Maiores detalhes sobre NCM podem ser encontrados em [Soares & Rodrigues 2005] Regiões Uma região (region) é definida como uma área no dispositivo de saída onde um nó de mídia pode ser exibido. Para organizar o layout das diversas partes do documento hipermídia, as regiões podem ser aninhadas. Em NCL, as regiões devem ser definidas no cabeçalho do programa (<head>), na seção de base de regiões (<regionbase>). Todo documento NCL possui pelo menos uma região, que define a dimensão e as características da tela onde um ou mais nós de mídia serão apresentados. Uma região serve para posicionar os nós de mídia em locais específicos. Uma região para que o vídeo seja apresentado no centro de uma tela com resolução de 720x576 pixels seria: <region id="rgvideo1" left="200" top="168" width="320" height="240" /> A Figura 1.2 ilustra a região definida no exemplo acima: Figura 1.2. Definição de regiões da tela. Todas as regiões devem ser definidas no cabeçalho do programa (<head>), contidas na seção de base de regiões (<regionbase>). A NCL define os seguintes atributos de região: id: identificador único, utilizado nas referências à região (por exemplo, nos descritores das mídias que são apresentadas na região) title (título): título da região, cujo uso depende da implementação do formatador

6 left (esquerda): coordenada x do lado esquerdo da região, com relação à coordenada do lado esquerdo da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra) top (topo): coordenada y do lado superior da região, com relação à coordenada do lado superior da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra) right (direita): coordenada x do lado direito da região, com relação à coordenada do lado esquerdo da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra) bottom (base): coordenada y do lado inferior da região, com relação à coordenada do lado superior da região pai (ou da tela, no caso de a região não estar aninhada a nenhuma outra) width (largura) e height (altura): dimensões horizontal e vertical da região. Cabe observar que o autor pode escolher especificar as dimensões de uma região de acordo com a melhor conveniência. Por exemplo, em certos casos pode ser melhor definir os atributos right, bottom, width, height. Em outros casos, pode ser mais apropriado especificar os atributos top, left, width e height. zindex: posição da região no eixo z, utilizado geralmente para indicar, no caso de regiões sobrepostas, quais regiões aparecem sobre quais outras. Camadas com zindex maior são apresentadas no topo de (sobrepondo) camadas com zindex menor Descritores Um descritor (descriptor) define como um nó de mídia será apresentado, incluindo a associação com uma região onde será exibido. Em NCL, todos os descritores devem ser definidos no cabeçalho do programa (<head>), na seção de base de descritores (<descriptorbase>). Um descritor do vídeo pode ser definido da seguinte maneira: <descriptor id="dvideo1" region="rgvideo1" /> Este descritor é identificado como dvideo1 e se refere à região rgvideo1. A NCL define os seguintes atributos de descritor: id: identificador único, utilizado nas referências ao descritor (por exemplo, nos nós de mídia/conteúdo apresentados pelo descritor) player: identifica a ferramenta de apresentação a ser utilizada para exibir o objeto de mídia associado ao descritor. Esse atributo é opcional. Quando omitido, a máquina de apresentação procura pela ferramenta default em função do tipo do objeto de mídia. explicitdur: define a duração ideal do objeto de mídia associado ao descritor. Na máquina de apresentação atual, o valor deste atributo só pode ser expresso em segundos, e deve estar no formato 9.9s (valor numérico seguido da letra s ). Quando explicitdur não for especificado, o objeto que estiver associado ao descritor será exibido com sua duração default. Mídias como textos e imagens estáticas possuem duração default infinita. region: identificador de uma região associada ao descritor. Ao utilizar o descritor o objeto será exibido na região correspondente. Esse atributo só precisa ser especificado para objetos que possuam um conteúdo visual a ser exibido.

7 A NCL define ainda o seguinte elemento contido num elemento de descritor: descriptorparam: define parâmetros do descritor como pares <atributo, valor>. Os atributos e seus respectivos valores dependem do programa de exibição da mídia associada ao descritor. Cada descritor pode conter diversos elementos descriptorparam, definidos no formato: <descriptorparam name="nome_do_parametro" value="valor_do_parametro" /> Por exemplo, um descritor pode definir um parâmetro adicional soundlevel, com o valor 1, para indicar que a mídia correspondente deve ser reproduzida com o volume máximo: <descriptor id="dvideo1" region="rgvideo1"> <descriptorparam name="soundlevel" value="1" /> </descriptor> O uso de parâmetros de descritor promove um alto grau de flexibilidade. Cabe ao programa de exibição do objeto de mídia interpretar esses atributos da forma adequada Portas Uma porta (port) é um ponto de interface (interface point) de um contexto, que oferece acesso externo ao conteúdo de um contexto. Em outras palavras, para um elo apontar para um nó interno ao contexto, este contexto deve possuir uma porta que leve ao nó interno (Figura 1.3). Figura 1.3. Porta pinicio como ponto de entrada a um nó interno de um contexto. Observe que o elemento body de um documento NCL é um contexto que herda o id do próprio documento. Sendo assim, em todo documento, deve haver pelo menos uma porta de entrada (port na seção body) indicando qual é o nó de mídia ou contexto inicial. Uma porta pode ser definida da seguinte forma: <port id="pinicio" component="video1" />

8 Observe que o atributo component dessa porta aponta para o nó de mídia video1. Isto significa que, ao iniciar o documento hipermídia, a máquina de apresentação seguirá a porta pinicio, que leva ao nó video1, que por sua vez será exibido. Uma porta possui os seguintes atributos: id: identificador único da porta, utilizado nas referências à porta (por exemplo, por elos) component: nó de mídia ou contexto ao qual a porta se aplica. interface: nome do ponto de interface (porta) de destino no contexto ou nome da âncora de destino no nó de mídia ou contexto. Caso component seja um contexto, pode-se definir ainda o atributo interface, apontando para uma porta ou âncora daquele contexto. Caso component seja um nó de mídia, pode-se definir o atributo interface apenas como sendo uma âncora do nó de mídia. Em ambos os casos, se o atributo interface for omitido, todo o nó será considerado como sendo a âncora de destino daquela porta Âncoras As âncoras são pontos de entrada para os nós de mídia ou contextos. O objetivo de se utilizar âncoras é utilizar segmentos de um nó de mídia ou contexto, seja como origem ou destino de elos. Uma âncora pode ser do tipo âncora de conteúdo (content anchor) ou âncora de propriedade (property anchor). Uma âncora de conteúdo define um segmento da mídia (intervalo de tempo e/ou região no espaço) que poderá ser utilizado como ponto de ativação de elos. Cada nó de mídia é composto de unidades de informação (information units). A definição dessas unidades de informação depende do tipo de mídia representado pelo nó. As unidades de informação de um vídeo, por exemplo, podem ser os frames do vídeo. Uma âncora consiste numa seleção contígua de unidades de informação de um nó. Uma âncora de conteúdo é definida como um elemento area dentro do elemento media. No exemplo abaixo, são definidas três âncoras de conteúdo para um nó de vídeo: <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo1">  <area id="avideolegenda01" begin="5s" end="9s"/> <area id="avideolegenda02" begin="10s" end="14s"/> <area id="avideolegenda03" begin="15s" end="19s"/> </media> A NCL define os seguintes atributos de âncora de conteúdo: id: identificador único da âncora coords: coordenadas em pixels da âncora espacial âncora (atributo válido para mídias visuais). begin e end: início e término e duração da âncora, em segundos, no formato 99.9s text: texto da âncora no arquivo de origem (atributo válido para mídias de texto) position: posição do texto da âncora no arquivo de origem (atributo válido para mídias de texto)

9 first e last: quadro/amostra da mídia definindo o início e término da âncora (atributo válido para mídias contínuas) label: identificador da âncora no arquivo de origem, tal como interpretado pela ferramenta de exibição. Já as âncoras de propriedade se referem a atributos de um nó de origem ou de destino, que podem ser manipulados pelos elos. Exemplos de atributos são: volume de áudio de um nó de áudio ou vídeo, coordenadas e dimensões de exibição de um nó de mídia visual, entre outros. Uma âncora de propriedade é definida como um elemento property dentro do elemento media ou context. No exemplo a seguir são definidas quatro âncoras de propriedade para um nó de vídeo, além da âncora de conteúdo:

10 <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo1">  <property name="top"/> <property name="left"/> <property name="width"/> <property name="height"/>  <area id="avideo1imagem1" begin="3s" end="8s"/> </media> Contextos (ou nós de composição) Contextos ou nós de composição são utilizados para estruturar um documento hipermídia. Os contextos podem ser aninhados, para refletir a estrutura do documento e ajudar o autor a organizar os segmentos do programa audiovisual interativo. Um contexto é definido da seguinte forma: <context id=" ncnome"> </context> Os atributos mais comuns de um contexto são: id: identificador único do contexto refer: referência a um outro contexto previamente definido (utiliza os atributos (exceto o id) do contexto referenciado) Vale lembrar que o elemento body é considerado um caso particular de contexto, representando o documento como um todo Nó de mídia (ou nó de conteúdo) Um nó de mídia ou de conteúdo (media node ou content node) define o objeto de mídia propriamente dito: vídeo, áudio, texto etc. Cada definição de nó de mídia deve apresentar, além do arquivo de origem da mídia, o descritor que regulará a apresentação daquele objeto de mídia. No exemplo a seguir é definido um nó de mídia do tipo vídeo: <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo1"/> Um nó de mídia possui os seguintes atributos: id: identificador único do nó de mídia, utilizado nas referências ao nó (por exemplo, nas portas dos nós de contexto que levam à mídia) type: tipo de mídia. Há diversos tipos de mídia MIME: video, audio, text (páginas HTML ou TXT), image ou img (imagens JPEG, PNG ou BMP), nclet (código Java de um NCLet), lua (arquivo com código Lua) e settings (nó de propriedades globais para ser usado em escolhas (switches)). src: fonte do objeto de mídia. Trata-se do caminho relativo para o arquivo de mídia, a partir do diretório onde se encontra o arquivo NCL. O caminho também pode ser especificado de forma absoluta, através de uma URI. descriptor: identificador do descritor que controla a apresentação do objeto de mídia

11 refer: referência a um outro nó de mídia previamente definido (utiliza os atributos (exceto o id) do nó de mídia referenciado) Elos Os elos (links) associam nós através de conectores (connectors), que definem a semântica da associação entre os nós. A NCL define os seguintes atributos de elos: id: identificador único do elo xconnector: identificador do conector associado ao elo A NCL define os seguintes elementos contidos num elemento de elo: linkparam: define parâmetros do elo como pares <atributo, valor>. Os atributos e seus respectivos valores dependem da definição do conector ao qual o elo está associado. bind: indica os componentes (component, nós de mídia e de contexto) envolvidos no elo, indicando o papel (role) de cada nó no elo, conforme a semântica do conector. Em alguns casos deve-se indicar também o ponto de interface (interface) do nó ao qual o elo é ligado. O elemento bind pode ainda conter uma ou mais instâncias do seguinte elemento como elementos filhos: bindparam: define parâmetros específicos do bind como pares <atributo, valor>. Os atributos e seus respectivos valores dependem da definição do conector ao qual o elo está associado Conectores No NCM, o sincronismo não é feito por marcas de tempo (timestamps), mas sim por mecanismos de causalidade e restrição definidos nos conectores (connectors). O conector define os papéis (roles) que os nós de origem e de destino exercem nos elos que utilizam o conector. A Figura 1.4 ilustra um conector ligando três nós. Figura 1.4. Ilustração de um conector ligando três nós.

12 Há dois tipos de conectores: causal (causal connector) e de restrição (constraint connector). Para a TV Digital, a NCL usa apenas conectores causais, os quais definem dois ou mais papéis, que indicam as condições de ativação do elo (simplecondition e compoundcondition) e as ações a serem realizadas quando o elo for ativado (simpleaction e compoundaction) Eventos A Figura 1.5 apresenta a máquina de estados de um evento (propositalmente em inglês para haver correspondência direta com NCL). Um evento pode estar em um dos seguintes estados: dormindo, preparando, preparado, ocorrendo, suspenso e abortado. Um evento é a exibição (evento de exibição) ou seleção (evento de seleção) de um conjunto não vazio de unidades de informação (segmento de mídia). Um evento também pode ser de atribuição, quando se dá a mudança de um atributo de um nó ou a de comportamento (definido no respectivo objeto descritor). O início ou fim de um evento é instantâneo (duração zero ou infinitesimal) e é denominado ponto de sincronização. A transição de estados de um evento é comumente usada em NCL para definir conectores. Figura 1.5. Máquina de estados de eventos Desenvolvimento de Aplicações em NCL A Tabela 1.1 apresenta a estrutura básica de um documento NCL. Todo documento NCL possui um cabeçalho de arquivo NCL (linhas 1 a 3), uma seção de cabeçalho do programa (seção head, linhas 4 a 14), o corpo do programa (seção body, linhas 15 a 18), e a conclusão do documento (linha 19). No corpo do programa é que são definidos os contextos, nós de mídia, elos e outros elementos que definem o conteúdo e a estrutura do programa. Como ponto de entrada no documento, deve-se definir portas (porta pinicio, linha 16), que determinam onde a apresentação do programa pode se iniciar. Ao exibir o documento, deve-se informar a porta por onde a exibição do documento se inicia (i.e., passar o identificador da porta como parâmetro para a máquina de apresentação). Caso uma porta não seja informada no momento de exibir o documento, nada será exibido como resultado de tocar aquele documento. cabeçalho do arquivo NCL cabeçalho programa do Tabela 1.1: Estrutura básica de um documento NCL. 1: <?xml version="1.0" encoding="iso "?> 2: 3: <ncl id="exemplo01" xmlns=" 4: <head> base de 5: <regionbase>

13 regiões 6:  7: </regionbase> base de 8: <descriptorbase> descritores 9:  10: </descriptorbase> base de conectores corpo programa do ponto de entrada no programa conteúdo do programa término do arquivo NCL 11: <connectorbase> 12:  13: </connectorbase> 14: </head> 15: <body> 16: <port id="pinicio" component="ncprincipal" interface="iinicio"/> 17:  18: </body> 19: </ncl> Geralmente, os passos para se construir um documento NCL são: 1. escrever o cabeçalho básico; 2. definir as regiões da tela onde aparecerão os elementos visuais (regionbase); 3. definir como e onde os nós de mídia serão exibidos, através de descritores (descriptorbase); 4. definir os conectores que especificam o comportamento dos elos do documento (connectorbase); 5. definir o conteúdo (nós de mídia) e a estrutura (contextos) do documento (seção body), associando-os aos descritores; 6. definir âncoras para os nós de mídia, visando à construção dos elos de/para nós de mídia; 7. definir portas para os contextos, visando à construção dos elos entre contextos e nós de mídia e incluindo a porta de entrada do programa, apontando para o primeiro nó a ser exibido; e 8. definir elos para o sincronismo e interatividade entre os nós de mídia e contextos Sincronizando um vídeo com um único arquivo de legenda, segmentado Esta seção apresenta um documento NCL que reproduz um vídeo no centro da tela e sincroniza uma legenda com o vídeo. A legenda é composta de um único arquivo HTML, contendo três elementos DIV, cada qual com um texto a ser sincronizado com o vídeo. Para reproduzir um vídeo, é necessário criar os seguintes elementos (indicados na Listagem 1.1): as regiões da tela onde o vídeo e a legenda serão exibidos (regiões rgvideo1 e rglegenda, linhas 34 e 35, respectivamente);

14 a associação das mídias com as regiões e a forma como serão exibidas (descritores dvideo1 e dlegenda, linhas 45 e 46); a(s) porta(s) que define(m) o ponto de entrada do documento hipermídia (porta pinicio, linha 73), que aponta para o primeiro elemento de mídia, video1; os nós de mídia do vídeo e das legendas (linhas 80 a 89). Os três nós de legenda se referenciam ao mesmo arquivo HTML, assim sua fonte (atributo src) ficará no formato nome_do_arquivo#id_do_div, como em legendas.html#legenda01 (linhas 87 a 89). Para definir os pontos do vídeo em que a legenda deve aparecer, é necessário criar âncoras para o vídeo, cada qual definindo o intervalo de exibição da legenda correspondente. Em seguida, basta criar três elos, cada qual para iniciar e terminar a exibição de cada legenda. A origem de cada elo deve ser uma das âncoras do vídeo, e o destino a legenda correspondente. A listagem a seguir apresenta o código necessário para reproduzir o vídeo com a legenda sincronizada. É importante reparar que todo elemento da NCL (região, descritor, nó de mídia, porta etc.) deve possuir um identificador único, representado pelo atributo id. Os demais atributos serão descritos nas seções seguintes, que aprofundam a definição de cada elemento utilizado no exemplo. Listagem 1.1: Documento NCL para reprodução de um vídeo com três trechos de legenda sincronizados, num único arquivo 1. 1: <?xml version="1.0" encoding="isso "?> 2: <! : EXEMPLO 01 4: 5: Objetivo: Reproduzir um vídeo numa região da tela, sincronizando com trechos 20: de legenda. 6: 7: Características: 8: 9: - sincronismo: simples (de início e término de mídias) 10: - interação do usuário: nenhuma 11:! > 12: 13: <! :! CABEÇALHO NCL: 15:! define as URIs dos esquemas da NCL 16:! > 17: 18: <ncl id="exemplo01" xmlns=" 19: 20: 21: 22: <! :! CABEÇALHO DO PROGRAMA 24:! > 25: 26: <head> 27: 28: <! Para executar este exemplo, é necessário que haja, no subdiretório media sob o diretório onde o arquivo NCL estiver localizado, as seguintes mídias: um vídeo chamado video1.mpg; e um arquivo HTML chamados legendas.html, contendo três elementos DIV identificados por legenda01, legenda02 e legenda03, cada qual com um texto a ser sincronizado.

15 29:! BASE DE REGIÕES: 30:! define as regiões na tela onde as mídias são apresentadas 31:! > 32: 33: <regionbase> 34: <region id="rgvideo1" left="200" top="168" width="320" height="240" zindex="1"/> 35: <region id="rglegenda" left="200" top="450" width="240" height="50" zindex="1" /> 36: </regionbase> 37: 38: <! :! BASE DE DESCRITORES: 40:! define como as mídias são apresentadas 41:! > 42: 43: <descriptorbase> 44: 45: <descriptor id="dvideo1" region="rgvideo1" /> 46: <descriptor id="dlegenda" region="rglegenda"/> 47: 48: </descriptorbase> 49: 50: <! :! BASE DE CONECTORES: 52:! definem o comportamento dos elos 53:! > 54: 55: <connectorbase> 56: <importbase alias="connectors" baseuri="connectorbase.ncl"/> 57: </connectorbase> 58: 59: </head> 60: 61: <! :! CORPO DO PROGRAMA: 63:! define as mídias e estrutura do programa 64:! > 65: 66: <body> 67: 68: <! :! PONTO DE ENTRADA: 70:! indica o componente onde o programa inicia 71:! > 72: 73: <port id="pinicio" component="video1" /> 74: 75: <! :! MÍDIAS: 77:! define o local dos arquivos de mídia e as associa com seus descritores 78:! > 79: 80: <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo1"> 81:  82: <area id="avideolegenda01" begin="5s" end="9s"/> 83: <area id="avideolegenda02" begin="10s" end="14s"/> 84: <area id="avideolegenda03" begin="15s" end="19s"/> 85: </media> 86: 87: <media type="text/html" id="legenda01" src="media/legendas.html#legenda01" descriptor="dlegenda" /> 88: <media type="text/html" id="legenda02" src="media/legendas.html#legenda02" descriptor="dlegenda" /> 89: <media type="text/html" id="legenda03" src="media/legendas.html#legenda03" descriptor="dlegenda" /> 90: 91: <! :! ELOS 93:! define os elos que regem o sincronismo entre as mídias 94:! > 95: 96:  97: <link id="llegenda01_start" xconnector="connectors#onbegin1startn"> 98: <bind component="video1" interface="avideolegenda01" role="onbegin" /> 99: <bind component="legenda01" role="start" /> 100: </link>

16 101: 102:  103: <link id="llegenda01_stop" xconnector="connectors#onend1stopn"> 104: <bind component="video1" interface="avideolegenda01" role="onend" /> 105: <bind component="legenda01" role="stop" /> 106: </link> 107: 108:  109: <link id="llegenda02_start" xconnector="connectors#onbegin1startn"> 110: <bind component="video1" interface="avideolegenda02" role="onbegin" /> 111: <bind component="legenda02" role="start" /> 112: </link> 113: 114:  115: <link id="llegenda02_stop" xconnector="connectors#onend1stopn"> 116: <bind component="video1" interface="avideolegenda02" role="onend" /> 117: <bind component="legenda02" role="stop" /> 118: </link> 119: 120:  121: <link id="llegenda03_start" xconnector="connectors#onbegin1startn"> 122: <bind component="video1" interface="avideolegenda03" role="onbegin" /> 123: <bind component="legenda03" role="start" /> 124: </link> 125: 126:  127: <link id="llegenda03_stop" xconnector="connectors#onend1stopn"> 128: <bind component="video1" interface="avideolegenda03" role="onend" /> 129: <bind component="legenda03" role="stop" /> 130: </link> 131: </body> 132: </ncl> As visões temporal e espacial deste exemplo são ilustradas na Figura 1.6.

17 Figura 1.6. Visões temporal e espacial do Exemplo 1, que reproduz um vídeo sincronizando uma legenda. As seguintes tabelas descrevem os conectores onbegin1startn e onend1stopn utilizados no Exemplo 1: Tabela 1.2: Conector onbegin1startn. Nome: Tipo: Condição: Ação: Código: onbegin1startn Causal início de exibição de um nó de mídia (definido no papel onbegin) dispara o início de exibição de um ou mais nós de mídia (definidos no papel start) <causalconnector id="onbegin1startn"> <simplecondition role="onbegin"/> <simpleaction role="start" max="unbounded"/> </causalconnector> Tabela 1.3: Conector onendstop. Nome: Tipo: Condição: Ação: Código: onend1stopn Causal término de exibição de um nó de mídia (definido no papel onend) encerra a exibição de um ou mais nós de mídia (definidos no papel stop) <causalconnector id="onend1stopn"> <simplecondition role="onend"/> <simpleaction role="stop" max="unbounded"/> </causalconnector>

18 1.4.2 Redimensionando uma região de vídeo durante a exibição de uma imagem Esta seção apresenta um documento NCL que reproduz um vídeo em tela inteira (720 x 576 px) e que, num determinado momento, é redimensionado para dar lugar a uma imagem na parte inferior da tela. A listagem a seguir apresenta o código necessário para redimensionar o vídeo quando uma imagem aparecer, a 3 segundos do início do vídeo, e para restaurar o tamanho original, a 8 segundos do vídeo. Para manipular os atributos top, left, width e height da região à qual o vídeo está associado, é necessário definir explicitamente esses atributos como atributos da mídia, ou então especificar o atributo bounds para manipular os atributos em conjunto (linha 54). A manipulação é feita através dos elos Video1Imagem1_start e Video1Imagem1_stop (linhas 61 a 78). Os conectores onbegin1resize1startnstopn e onend1resize1startnstopn serão vistos no final desta seção. Listagem 1.2: Documento NCL para redimensionamento de um vídeo enquanto uma imagem está sendo exibida 2. 1: <?xml version="1.0" encoding="iso "?> 2: 3: <! : EXEMPLO 02 5: 6: Objetivo: Reproduzir um vídeo numa região da tela e redimensioná-lo num momento 7: de sincronização com uma imagem 8: 9: Características: 10: 11: - sincronismo: simples (de início e término de uma mídia) 12: - interação do usuário: nenhuma 13:! > 14: 15:  16: 17: <ncl id="exemplo02" xmlns=" 18: 19:  20: <head> 21: 22:  23: <regionbase> 24: <region id="rgvideo1" left="200" top="168" width="320" height="240" zindex="1"/> 25: <region id="rgimagem1" left="200" top="190" width="504" height="377" zindex="1" /> 26: </regionbase> 27: 28:  29: <descriptorbase> 30: <descriptor id="dvideo1" region="rgvideo1"> 31: <descriptorparam name="soundlevel" value="1" /> 32: </descriptor> 33: <descriptor id="dimagem1" region="rgimagem1" /> 34: </descriptorbase> 35: 36:  37: <connectorbase> 38: <importbase alias="connectors" baseuri="connectorbase.ncl"/> 39: </connectorbase> 40: 41: </head> 42: 43:  2 Para executar este exemplo, é necessário que haja, no subdiretório media sob o diretório onde o arquivo NCL estiver localizado, as seguintes mídias: um vídeo chamado video1.mpg; e uma imagem chamada imagem1.png.

19 44: <body> 45: 46:  47: <port id="pinicio" component="video1" /> 48: 49:  50: <media type="vídeo/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo1"> 51:  52: <area id="avideo1imagem1" begin="3s" end="8s"/> 53:  54: <property name="bounds" /> 55: </media> 56: 57: <media type="image/png" id="imagem1" src="media/imagem1.png" descriptor="dimagem1" /> 58: 59:  60: 61:  62: <link id="video1imagem1_start" xconnector="connectors#onbegin1resize1startnstopn"> 63: <bind component="video1" interface="avideo1imagem1" role="onbegin" /> 64: <bind component="video1" interface="bounds" role="setbounds"> 65: <bindparam name="bounds" value="200,18,160,120" /> 66:  67: </bind> 68: <bind component="imagem1" role="start" /> 69: </link> 70: 71:  72: <link id="video1imagem1_stop" xconnector="connectors#onend1resize1startnstopn"> 73: <bind component="video1" interface="avideo1imagem1" role="onend" /> 74: <bind component="video1" interface="bounds" role="setbounds"> 75: <bindparam name="bounds" value="200,168,320,240" /> 76: </bind> 77: <bind component="imagem1" role="stop" /> 78: </link> 79: 80: </body> 81: </ncl> A Figura 1.7 ilustra as visões temporal e espacial do Exemplo 2.

20 Figura 1.7: Visões temporal e espacial do documento que redimensiona um vídeo sincronizado a uma imagem. A tabela a seguir descreve o conector onbegin1resize1startnstopn. Tabela 1.4: Conector onbegin1resize1startnstopn. Nome: Tipo: Condição: onbegin1resize1startnstopn Causal início de exibição da mídia no papel onbegin Ação: altera as coordenadas e dimensões da mídia do nó de destino, conforme os parâmetros passados pelo elo (linkparam ou bindparam) para a variável do conector (connectorparam) denominada bounds, utilizada pelo papel setbounds; pode exibir mídias no papel start; e pode ocultar mídias no papel stop. Observação: Os elos que utilizarem este conector deverão identificar, como parâmetro adicional do elo (linkparam) ou do bind (bindparam), as novas coordenadas e dimensões (x,y,w,h). Por exemplo: Código: <linkparam name="bounds" value="200,18,160,120" /> <causalconnector id="onbegin1resize1startnstopn"> <connectorparam name="bounds"/> <simplecondition role="onbegin"/> <compoundaction operator="seq"> <simpleaction role="set" value="$bounds"/> <simpleaction role="start" max="unbounded"/> <simpleaction role="stop" max="unbounded"/> </compoundaction> </causalconnector> O conector onend1resize1startnstopn é análogo ao anterior, mas substitui a condição onbegin por: <simplecondition role="onend"/> Alternando imagens para identificar ações disponíveis O objetivo deste exemplo é permitir ao usuário alternar entre dois vídeos, através da seleção das teclas vermelha e verde do controle remoto da TV Digital. Ambos os vídeos

21 devem ser apresentados na mesma posição da tela e devem ser iniciados de forma sincronizada, sendo que um deles deve iniciar invisível e sem som. Quando o usuário fizer uma seleção com os botões do controle remoto, os atributos de visibilidade e volume de áudio dos dois vídeos devem ser invertidos. Como as duas mídias tocarão ao mesmo tempo, mas com parâmetros de visibilidade e som distintos, um novo descritor para o segundo vídeo (video2, linha 64) é criado (dvideo2, linha 37) reusando a mesma região do video1 mas com os valores dos atributos correspondentes definidos no seu descritor (linhas 38 e 39) para que não haja som nem exibição no início. Para que seja possível alterar os atributos visible e soundlevel, é necessário que esses atributos estejam definidos explicitamente no nó de mídia correspondente (linhas e 65-66). Finalmente, é necessário criar dois elos para efetuar a seleção do vídeo, através do conector onselectiontogglevideo (linhas 89 a 109). Como será visto adiante, esse conector troca o vídeo sendo exibido, conforme o botão selecionado: o botão vermelho ativa o video1 e o botão verde ativa o video2. Observa-se que, como o elo deve alterar algumas propriedades dos nós de vídeo, cada elemento de ligação (bind) deve especificar não apenas o componente de destino do elo (atributo component), mas também a sua propriedade (atributo interface), tal como definido no nó da mídia: <bind component="video1" interface="avideo1visible" role="setvisibilityon"/> A princípio, as imagens dos botões vermelho e verde ficariam o tempo todo visíveis, mas somente um dos botões causa efeito ao ser pressionado. Como isto pode causar problemas de usabilidade, será modificada a visibilidade das imagens correspondentes aos botões sempre que uma seleção for feita, de modo que apenas o botão que possa causar uma mudança do vídeo seja exibido. Em primeiro lugar, o elo de exibição inicial do vídeo e dos botões não deve exibir o botão verde, pois pressionar a tecla verde enquanto o vídeo 1 está tocando não produz efeito. Além disto, é preciso incluir dois elos, que alternam a exibição das imagens correspondentes aos botões (linhas 111 a 127). Esses elos utilizam o conector onselection1startnstopn, especificado para modificar a visibilidade de um ou mais nós de mídia conforme o pressionamento de uma determinada tecla. A Listagem 1.3 apresenta o código deste exemplo. Listagem 1.3: Documento NCL com elos para alternar a exibição de imagens e vídeos através da interação do usuário 3. 1: <?xml version="1.0" encoding="iso "?> 2: 3: <! : EXEMPLO 03 5: 6: Objetivo: Reproduzir um vídeo e permitir que o usuário alterne entre dois vídeos, 7: numa mesma região da tela, através do pressionamento das teclas 8: vermelha e verde do controle remoto. Oculta a imagem correspondente ao 9: botão que não fizer efeito no momento. 10: 3 Para executar este exemplo, é necessário que haja, no subdiretório media, sob o diretório onde o arquivo NCL estiver localizado, as seguintes mídias: dois arquivos de vídeo, chamados video1.mpg e video2.mpg; e duas imagens, chamadas botao_vermelho.png e botao_verde.png, representando os botões vermelho e verde, respectivamente.

22 11: Características: 12: 13: - sincronismo: ponto de alternância entre os vídeos 14: - interação do usuário: seleção do vídeo a ser exibido 15: 16:! > 17: 18:  19: 20: <ncl id="exemplo03" xmlns=" 21: 22: 23: 24:  25: <head> 26: 27:  28: <regionbase> 29: <region id="rgvideo1" left="200" top="168" width="320" height="240" /> 30: <region id="rgbotaovermelho" left="200" top="420" width="25" height="25" /> 31: <region id="rgbotaoverde" left="200" top="470" width="25" height="25" /> 32: </regionbase> 33: 34:  35: <descriptorbase> 36: <descriptor id="dvideo1" region="rgvideo1" /> 37: <descriptor id="dvideo2" region="rgvideo1"> 38: <descriptorparam name="visible" value="false" /> 39: <descriptorparam name="soundlevel" value="0"/> 40: </descriptor> 41: <descriptor id="dbotaovermelho" region="rgbotaovermelho" /> 42: <descriptor id="dbotaoverde" region="rgbotaoverde" /> 43: </descriptorbase> 44: 45:  46: <connectorbase> 47: <importbase alias="connectors" baseuri="connectorbase.ncl"/> 48: </connectorbase> 49: 50: </head> 51: 52:  53: <body> 54: 55:  56: <port id="pinicio" component="video1" /> 57: 58:  59: <media type="video/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo1"> 60: <attribute id="avideo1visible" name="visible" /> 61: <attribute id="avideo1soundlevel" name="soundlevel" /> 62: </media> 63: 64: <media type="video/mpeg" id="video2" src="media/video2.mpg" descriptor="dvideo2"> 65: <attribute id="avideo2visible" name="visible" /> 66: <attribute id="avideo2soundlevel" name="soundlevel" /> 67: </media> 68: 69: <media type="image/png" id="botaovermelho" src="media/botao_vermelho.png" descriptor="dbotaovermelho"/> 70: <media type="image/png" id="botaoverde" src="media/botao_verde.png" descriptor="dbotaoverde" /> 71: 72:  73: 74:  75: <link id="lvideo_botoes_start" xconnector="connectors#onbegin1startn"> 76: <bind component="video1" role="onbegin" /> 77: <bind component="video2" role="start" /> 78: <bind component="botaovermelho" role="start" /> 79: </link> 80: 81:

23 82: <link id="lvideo_botoes_stop" xconnector="connectors#onend1stopn"> 83: <bind component="video1" role="onend" /> 84: <bind component="video2" role="stop" /> 85: <bind component="botaoverde" role="stop" /> 86: <bind component="botaovermelho" role="stop" /> 87: </link> 88: 89:  90: <link id="lselecionavideo2" xconnector="connectors#onselection1togglevideo"> 91: <bind component="botaovermelho" role="onselection"> 92: <bindparam name="keycode" value="red"/> 93: </bind> 94: <bind component="video1" interface="avideo1visible" role="setvisibilityoff"/> 95: <bind component="video1" interface="avideo1soundlevel" role="setsoundleveloff"/> 96: <bind component="video2" interface="avideo2visible" role="setvisibilityon"/> 97: <bind component="video2" interface="avideo2soundlevel" role="setsoundlevelon"/> 98: </link> 99: 100:  101: <link id="lselecionavideo1" xconnector="connectors#onselection1togglevideo"> 102: <bind component="botaoverde" role="onselection"> 103: <bindparam name="keycode" value="green"/> 104: </bind> 105: <bind component="video1" interface="avideo1visible" role="setvisibilityon"/> 106: <bind component="video1" interface="avideo1soundlevel" role="setsoundlevelon"/> 107: <bind component="video2" interface="avideo2visible" role="setvisibilityoff"/> 108: <bind component="video2" interface="avideo2soundlevel" role="setsoundleveloff"/> 109: </link> 110: 111:  112: <link id="ltogglebotaovermelho" xconnector="connectors#onselection1startnstopn"> 113: <bind component="botaovermelho" role="onselection"> 114: <bindparam name="keycode" value="red" /> 115: </bind> 116: <bind component="botaoverde" role="start" /> 117: <bind component="botaovermelho" role="stop" /> 118: </link> 119: 120:  121: <link id="ltogglebotaoverde" xconnector="connectors#onselection1startnstopn"> 122: <bind component="botaoverde" role="onselection"> 123: <bindparam name="keycode" value="green" /> 124: </bind> 125: <bind component="botaoverde" role="stop" /> 126: <bind component="botaovermelho" role="start" /> 127: </link> 128: </body> 129: </ncl> A Figura 1.8 ilustra as visões temporal e espacial do Exemplo 3:

24 Figura 1.8: Visões temporal e espacial do Exemplo 3, com sincronismo (conectores onbegin1startn e onend1stopn) e interação (conectores onselection1togglevideo e onselection1startnstopn). A tabela a seguir descreve o conector onselection1togglevideo. Observa-se que esse conector exige que o elo correspondente defina um parâmetro, do tipo connectorparam, para preencher o valor do atributo keycode, definido no elemento conditionrole. Tabela 1.5: Conector onselection1togglevideo. Nome: Tipo: Condição: onselection1togglevideo Causal tecla <keycode> acionada (papel onselection) Ação: torna visível a mídia identificada no papel setvisibilityon; torna invisível a mídia identificada no papel setvisibilityoff; estabelece o volume máximo para a mídia identificada no papel setvolumeon; e estabelece o volume mínimo (mute, ou sem som) para a mídia identificada no papel setvolumeoff Observações: Os elos que utilizarem este conector deverão identificar, como parâmetro adicional da ligação com o nó de origem (linkparam ou bindparam), o código virtual da tecla do controle remoto associada à seleção. Por exemplo: <bindparam name="keycode" value="vk_enter"/>

25 Código: <causalconnector id="onselection1togglevideo"> <connectorparam name="keycode" type="xsi:string"/> <simplecondition role="onselection" key= $keycode /> <compoundaction operator="seq"> <simpleaction role="setvisibilityon" eventtype="attribution" actiontype="start" value="true"/> <simpleaction role="setsoundlevelon" eventtype="attribution" actiontype="start" value="1"/> <simpleaction role="setvisibilityoff" eventtype="attribution" actiontype="start" value="false"/> <simpleaction role="setsoundleveloff" eventtype="attribution" actiontype="start" value="0"/> </compoundaction> </causalconnector> A tabela a seguir descreve o conector onselection1startnstopn. Observa-se que esse conector exige que o elo correspondente defina um parâmetro do tipo bindparam ou linkparam, para preencher o valor do atributo keycode, definido no elemento conditionrole. Tabela 1.6: Conector onselection1startnstopn. Nome: Tipo: Condição: onselection1startnstopn Causal tecla <keycode> acionada (papel onselection) Ação: exibe as mídias identificadas pelo papel start; oculta as mídias identificadas pelo papel stop Observação: Os elos que utilizarem este conector deverão identificar, como parâmetro adicional da ligação com o nó de origem (bindparam ou linkparam), o código virtual da tecla do controle remoto associada à seleção. Por exemplo: Código: <bindparam name="keycode" value="vk_enter" /> <causalconnector id="onselection1startnstopn"> <connectorparam name="keycode" type="xsi:string" /> <simplecondition role="onselection" key= $keycode /> <compoundaction operator="seq"> <simpleaction role="start" max="unbounded"/> <simpleaction role="stop" max="unbounded"/> </causalconnector> Simulação de um menu de DVD com feedback O objetivo deste exemplo é exibir um vídeo em loop, exibindo ao mesmo tempo duas opções de idioma. Ao selecionar uma das opções (pressionando a tecla verde ou vermelha do controle remoto da TV Digital), é exibido um vídeo de abertura (independente do idioma selecionado) e, em seguida, um vídeo sem som e um áudio de acordo com o idioma escolhido. Todos os vídeos devem ser apresentados na mesma posição da tela. Para armazenar a opção selecionada, será utilizado um nó do tipo settings com um atributo idioma (linhas 61 a 63). Já para selecionar o nó de áudio a ser reproduzido ao final do video2, são definidas rules (regras, linhas 41 a 45) e um switch (linhas 76 a 87). Quando o botão vermelho ou o verde é selecionado, o idioma correspondente é armazenado no atributo idioma, através do conector OnSelection1SetStartStopDelay (linhas 118 a 144). Este mesmo conector é o responsável por interromper o video1 e iniciar a exibição do video2. Quando o video2 termina, o elo lvideo2startvideo3, através do conector OnEnd1StartN, ativa o nó de contexto contextofilme (linhas 146 a 150). A porta desse contexto ativa o video3 (linha 72), que por sua vez dispara, sincronamente, através do conector onbegin1startn (linhas 89 a 93), o switch switchaudioidioma (linhas 76 a 87). Este switch é regido pelas regras ren e rpt (linhas 82 e 83), definidas

26 previamente na seção rulebase (linhas 41 a 45). Nota-se que foi criado um segundo descritor para o video3 (linhas 33 a 35), pois ele deve ser exibido sem som (soundlevel=0). Como boa prática de projeto de programa audiovisual interativo, deve-se fornecer um feedback para toda ação do usuário. Ao selecionar um idioma, por exemplo, o usuário precisa receber um feedback imediato sobre qual opção foi selecionada. Caso contrário, ele precisaria esperar o início da reprodução do áudio, após o video2, para saber se fez a seleção correta. Uma forma de se fazer isso é ocultar momentaneamente as opções que não foram selecionadas, deixando apenas a seleção do usuário visível, mesmo que por uma fração de segundo. Para atingir esse efeito, pode-se definir um atributo delay no mapeamento de ativação do conector. A Tabela 1.7 apresenta o conector OnSelection1SetStartStopDelay, para acomodar não apenas o disparo imediato de eventos, mas também um disparo retardado por meio segundo: Tabela 1.7: Definição do conector onselection1setstartstop, para introduzir papéis de ativação com retardo. Nome: Tipo: Condição: onselection1setstartstopdelay Causal tecla <keycode> acionada (papel onselection) Ação: exibe as mídias identificadas pelo papel start; pára as mídias identificadas pelo papel stop; aborta as mídias identificadas pelo papel abort; define o valor <valueset> ao atributo mapeado através do papel set; exibe, após um retardo de 0,5s, as mídias identificadas pelo papel dstart; pára, após um retardo de 0,5s, as mídias identificadas pelo papel dstop; e aborta, após um retardo de 0,5s, as mídias identificadas pelo papel dabort. Observação: Os elos que utilizarem este conector deverão identificar, como parâmetros adicionais da ligação com o nó de origem (bindparam ou linkparam), o código virtual da tecla do controle remoto associada à seleção e o valor a ser atribuído. Por exemplo: Código: <bindparam name="keycode" value="green" /> <bindparam name="valueset" value="en" /> <causalconnector id="onselection1setstartstopdelay"> <connectorparam name="keycode"/> <connectorparam name="valueset"/> <connectorparam name="delay"/> <simplecondition role="onselection" key="$keycode"/> <compoundaction operator="seq"> <simpleaction role="set" value="$valueset"/> <simpleaction role="start" delay="$delay"/> <simpleaction role="stop" delay="$delay"/> </compoundaction> </causalconnector> Fazendo uso desse conector, pode-se ocultar imediatamente a opção não selecionada e, após meio segundo, oculta-se a opção selecionada e substituir o video1 pelo video2. A Listagem 1.4 apresenta o código NCL desse exemplo. Listagem 1.4: Documento NCL para exibir um vídeo em loop e, mediante a seleção do usuário, substituí-lo por um segundo vídeo e, finalmente, exibir um terceiro vídeo e um áudio conforme a seleção de idioma, fornecendo feedback momentâneo. 1: <?xml version="1.0" encoding="iso "?> 2: 3: <! : EXEMPLO 04 5: 6: Objetivo: Reproduzir um vídeo e permitir que o usuário selecione 7: 1) o idioma do áudio, através do pressionamento das teclas 8: 2) vermelha e verde do controle remoto. 9: 10: Características:

27 11: 12: - sincronismo: simples (de início e término de mídias) 13: - interação do usuário: seleção do áudio a ser exibido 14:! > 15: 16:  17: <ncl id="exemplo04" xmlns=" 18: 19:  20: <head> 21: 22:  23: <regionbase> 24: <region id="rgvideo1" left="200" top="168" width="320" height="240" /> 25: <region id="rgaudio1" left="200" top="410" width="320" /> 26: <region id="rgbotaovermelho" left="200" top="420" width="25" height="25" /> 27: <region id="rgbotaoverde" left="200" top="470" width="25" height="25" /> 28: </regionbase> 29: 30:  31: <descriptorbase> 32: <descriptor id="dvideo1" region="rgvideo1" /> 33: <descriptor id="dvideo3" region="rgvideo1"> 34: <descriptorparam name="soundlevel" value="0" /> 35: </descriptor> 36: <descriptor id="daudio1" region="rgaudio1" /> 37: <descriptor id="dbotaovermelho" region="rgbotaovermelho" /> 38: <descriptor id="dbotaoverde" region="rgbotaoverde" /> 39: </descriptorbase> 40: 41:  42: <rulebase> 43: <rule id="ren" var="idioma" op="eq" value="en" /> 44: <rule id="rpt" var="idioma" op="eq" value="pt" /> 45: </rulebase> 46: 47:  48: <connectorbase> 49: <importbase alias="connectors" baseuri="connectorbase.ncl"/> 50: </connectorbase> 51: 52: </head> 53: 54:  55: <body> 56: 57:  58: <port id="pinicio" component="video1" /> 59: 60:  61: <media type=" application/x-ginga-setting" id="settings"> 62: <attribute id="idioma" name="idioma" /> 63: </media> 64: 65: <media type="video/mpeg" id="video1" src="media/video1.mpg" descriptor="dvideo3" /> 66: <media type="video/mpeg" id="video2" src="media/video2.mpg" descriptor="dvideo1" /> 67: <media type="image/png" id="botaovermelho" src="media/botao_vermelho.png" descriptor="dbotaovermelho" /> 68: <media type="image/png" id="botaoverde" src="media/botao_verde.png" descriptor="dbotaoverde" /> 69: 70:  71: <context id="contextofilme"> 72: <port id="pvideo3" component="video3" /> 73: 74: <media type="video/mpeg" id="video3" src="media/video3.mpg" descriptor="dvideo3" /> 75: 76: <! :! SWITCH: contexto que 78:! contém os áudios, com regra de seleção entre eles 79:! conforme o idioma

28 80:! > 81: <switch id="switchaudioidioma"> 82: <bindrule rule="ren" component="audioen" /> 83: <bindrule rule="rpt" component="audiopt" /> 84: 85: <media type="audio/mp3" id="audioen" src="media/audioen.mp3" descriptor="daudio1" /> 86: <media type="audio/mp3" id="audiopt" src="media/audiopt.mp3" descriptor="daudio1" /> 87: </switch> 88: 89:  90: <link id="lvideo3audiostart" xconnector="connectors#onbegin1startn"> 91: <bind component="video3" role="onbegin" /> 92: <bind component="switchaudioidioma" role="start" /> 93: </link> 94: 95:  96: <link id="lvideo3audiostop" xconnector="connectors#onend1stopn"> 97: <bind component="video3" role="onend" /> 98: <bind component="switchaudioidioma" role="stop" /> 99: </link> 100: 101: </context> 102: 103:  104: 105:  106: <link id="lvideo1init" xconnector="connectors#onbegin1startn"> 107: <bind component="video1" role="onbegin" /> 108: <bind component="botaovermelho" role="start" /> 109: <bind component="botaoverde" role="start" /> 110: </link> 111: 112:  113: <link id="lvideo1loop" xconnector="connectors#onend1start1"> 114: <bind component="video1" role="onend" /> 115: <bind component="video1" role="start" /> 116: </link> 117: 118:  119: <link id="lselectbotaovermelhoidioma" xconnector=" connectors#onselection1setstartstopdelay"> 120: <bind component="botaovermelho" role="onselection"> 121: <bindparam name="keycode" value="red" /> 122: </bind> 123: <bind component="settings" interface="idioma" role="set"> 124: <bindparam name="valueset" value="en" /> 125: </bind> 126: <bind component="botaoverde" role="stop" /> 127: <bind component="botaovermelho" role="stop" /> 128: <bind component="video1" role="stop" /> 129: <bind component="video2" role="start" /> 130: </link> 131: 132:  133: <link id="lselectbotaoverdeidioma" xconnector="connectors#onselection1setstartstopdelay"> 134: <bind component="botaoverde" role="onselection"> 135: <bindparam name="keycode" value="green" /> 136: </bind> 137: <bind component="settings" interface="idioma" role="set"> 138: <bindparam name="valueset" value="pt" /> 139: </bind> 140: <bind component="botaoverde" role="stop" /> 141: <bind component="botaovermelho" role="stop" /> 142: <bind component="video1" role="stop" /> 143: <bind component="video2" role="start" /> 144: </link> 145: 146:  147: <link id="lvideo2startvideo3" xconnector="connectors#onend1startn"> 148: <bind component="video2" role="onend" /> 149: <bind component="contextofilme" interface="pvideo3" role="start" /> 150: </link> 151:

29 152: </body> 153: </ncl> A Figura 1.9 ilustra as visões temporal e espacial do Exemplo 4: Figura 1.9: Visões temporal e espacial do Exemplo 4, com feedback momentâneo da seleção do usuário Outras possíveis linguagens Os principais middlewares declarativos existentes [ETSI 2005, ATSC 2005, ARIB 2004] são baseados em tecnologias desenvolvidas para a Web, mais especificamente XHTML [W3C 2002] com suporte a CSS [W3C 1998], DOM [W3C 2004] e ECMAScript [ECMA 1999]. De um modo geral, XHTML favorece a autoria em função da sua simplicidade e da sua disseminação como linguagem para especificação de documentos na Web. Entretanto, as funcionalidades dessa linguagem são restritas quando existe a necessidade de especificar o sincronismo na sua forma mais ampla, uma vez que XHTML restringe-se à formatação para apresentação e à definição de relações de referência entre documentos. Para superar essa limitação, as linguagens DVB-HTML (sistema europeu) [ETSI05], XDML (sistema americano) [ATSC05] e BML (sistema japonês) [ARIB04] adotam XHTML em conjunto com a linguagem ECMAScript. Todas essas linguagens acrescentam pequenas extensões à XHTML, mas apenas BML define extensões para descrever alguns tipos de sincronismo. Entretanto, mesmo as novas marcações definidas precisam, geralmente, ser complementadas com códigos

30 ECMAScript para descrever a ação a ser executada no relacionamento de sincronização. Além disso, certos relacionamentos de sincronização espaço-temporal, que não se encaixam nas extensões definidas por BML, também devem ser definidos através do uso de ECMAScript, por meio de uma especificação embutida, direta ou indiretamente, em um objeto XHTML. ECMAScripts apresentam um propósito mais geral que apenas a especificação de sincronismo, oferecendo uma maior flexibilidade para construção dos programas. No entanto, o nível de abstração oferecido para os autores é baixo, obrigando que os criadores dos programas de TV interativa trabalhem, na realidade, como programadores de software. Por ser uma linguagem orientada a sincronismo de mídias, NCL oferece, exclusivamente através do paradigma declarativo, um nível mais alto de abstração para a autoria de programas não-lineares, ao mesmo tempo que coloca uma rica expressividade para a descrição dos relacionamentos temporais e espaciais entre os objetos de mídia. As linguagens DVB-HTML, XDML e BML permitem a definição de características espaciais de apresentação de um componente em um objeto separado, utilizando CSS, similar ao modelo de regiões e descritores da linguagem NCL. Todavia, as características temporais de apresentação, tais como início, duração e fim da exibição, permanecem embutidas na definição dos objetos. Mais ainda, todas as linguagens, por serem baseadas em XHTML, implementam a sincronização temporal com interatividade por meio de elos embutidos no conteúdo dos documentos (exceto quando o sincronismo é realizado por eventos de sincronismo DSM-CC). Como desvantagem, isso faz com que a reutilização de um objeto (conteúdo) herde obrigatoriamente os seus relacionamentos. Em NCL, uma página XHTML é tratada como mais um objeto de mídia, e todas as informações temporais e de sincronização a ela relacionadas são descritas externamente ao objeto (através dos elos e descritores). Dessa forma, uma mesma página poderia assumir comportamentos distintos em programas NCL diferentes, favorecendo o reúso. Recentemente, os grupos de padronização dos vários sistemas internacionais de TV Digital estão dedicando uma atenção maior à importância do middleware declarativo e estão sinalizando com uma tendência a buscar linguagens com foco em sincronismo de mídias. O padrão W3C SMIL [W3C05] e a alternativa declarativa para especificação de documentos MPEG-4, denominada XMT [ISO01], são duas opções cogitadas, além da antiga proposição MHEG-5 [ISO97]. SMIL e XMT têm limitações ao explorar composições como mecanismo de sincronização, enquanto o MHEG-5 já foi criticado por sua complexidade. O paradigma de elos para sincronização utilizado pela linguagem NCL, com uso de composições para estruturação, não necessariamente temporal, dos documentos, contorna as potenciais desvantagens das composições temporais. A separação entre elos (relacionamentos) e conectores (relações), por outro lado, procura não tornar complexa a tarefa de autoria Ferramentas para Edição de Programas Não-Lineares Há várias ferramentas que facilitam a criação de programas para TV Digital Interativa [Guimarães & Costa, 2006]. Algumas delas foram projetadas especificamente para esse fim, como o JAME Author, o Cardinal Studio e o AltiComposer. Outras ferramentas foram voltadas para o desenvolvimento de documentos multimídia, como o GRiNS e o Maestro Editor.

31 O JAME Author é um ambiente de autoria para a criação de aplicativos de TV Digital Interativa para o middleware MHP/OCAP, e faz parte de um grupo de soluções para itv do Fraunhofer Institute for Media Communication IMK 4. O MHP oferece uma API Java (Xlet) que deixa o autor bastante livre para a concepção de aplicativos para a TV Digital Interativa de forma imperativa. Um efeito colateral dessa liberdade na autoria é que o processo de criação de aplicativos pode se tornar complexo já que eles devem ser feitos a partir do zero. O JAME Author é uma ferramenta voltada especificamente para a criação de uma classe especial de aplicativos chamados page-based services (Serviços Baseados em Páginas). Tais páginas são descritas por meio de uma linguagem especificamente voltada para esse fim. Cardinal Studio é uma ferramenta de autoria da Cardinal Systems 5 para a criação de aplicativos de TV Digital Interativa também por meio do middleware MHP. O modelo de autoria do Cardinal Studio tem como abstração de mais alto nível os Atos (Acts). Essas entidades servem para fazer a estruturação de um aplicativo, e podem ser entendidas como cenas. No Cardinal Studio, toda interatividade é definida através de eventos disparados pelos componentes, como, por exemplo, o evento actionperformed de um componente focável. Neste caso, esse evento é disparado quando o componente tem o foco e o um botão do controle remoto é pressionado. A ação executada pode ser personalizada de acordo com as intenções do autor mas a lista de quais eventos podem ocorrer é limitada, não havendo como o autor criar novos eventos. Assim como as duas ferramentas descritas anteriormente, o AltiComposer é um ambiente de autoria para se criar aplicativos em conformidade com o DVB-MHP. Desta forma o produto do trabalho desenvolvido nessa ferramenta visual é um Xlet que roda em set-top boxes compatíveis. O AltiComposer foi desenvolvido para dar suporte tanto a usuários não-programadores quanto aos que possuem um grande conhecimento de programação em Java. Para o primeiro grupo a ferramenta lança mão de uma interface gráfica intuitiva e muito funcional, onde vários recursos podem ser facilmente utilizados através do mouse. Por sua vez, usuários mais avançados podem estender a API Component Development Kit (CDK) para criar componentes personalizados. Os nomes de componentes utilizados no AltiComposer foram definidos de acordo com os termos utilizados na indústria de TV e cinema. O GRiNS Pro Editor for SMIL 2.0 é um ambiente de autoria para SMIL que possui várias visões integradas (temporal, espacial e textual). Contudo, essa ferramenta destaca-se por sua visão temporal para concepção de documentos. O objetivo principal dessa ferramenta é eximir do autor a necessidade de conhecer profundamente a linguagem SMIL. Na sua visão temporal é possível montar e manipular a apresentação no decorrer do tempo de forma bastante intuitiva. Diferentemente da edição na linha do tempo normal, o paradigma de linha do tempo estruturado (structured timeline) exibe composições estruturadas que definem as relações lógicas entre os objetos de mídia. Outro detalhe é que todas as composições mencionadas anteriormente são exibidas em cores diferentes na visão temporal, e isso permite ao autor identificar facilmente de qual 4 Disponível em 5 Disponível em

32 tipo se trata. Além das características mencionadas, o autor ainda pode ter uma estimativa do tempo da apresentação do documento. A visão espacial do GRiNS tem como objetivo fornecer ao autor um modo prático e ágil de criar e manipular regiões nas quais os objetos de mídia serão apresentados no espaço. Mesmo que na maior parte do tempo seja mais fácil se trabalhar nas visões gráficas, editar o código fonte em SMIL também pode ser bastante útil. É com essa intenção que a visão textual do GRiNS permite que o código seja não só visualizado como também editado, de forma que qualquer alteração nessa visão é devidamente refletida nas demais visões. O editor da visão textual é bem simples, e oferece somente os recursos básicos encontrados na maioria dos editores textuais disponíveis no mercado. O Composer é uma ferramenta para auxiliar na construção de documentos NCL. Esse editor é dividido em quatro visões: uma visão gráfica estrutural, uma visão gráfica temporal, uma visão gráfica de layout e uma visão textual. As quatro visões funcionam de maneira sincronizada, a fim de oferecer um ambiente integrado de autoria. Além disso, as visões são providas de mecanismos de filtragem para auxiliar na especificação de arquiteturas mais complexas [Coelho 2004]. A máquina de apresentação Ginga-NCL é responsável por exibir o documento NCL criado, mantendo suas características temporais e espaciais de sincronismo. A Figura 1.10 mostra o editor Composer com as quatro visões abertas. A região 1 exibe a base de documentos NCL na forma de uma árvore. A região 2 é a área de trabalho onde um documento pode ser editado em qualquer uma das visões. Através da autoria sincronizada entre as diferentes visões, o autor pode criar documentos NCL de forma mais rápida e simples porque pode se utilizar das vantagens de cada diferente visão em etapas específicas de edição do documento. A visão de layout, por exemplo, é aquela em que se definem as diferentes regiões de apresentação do documento; essa mesma etapa pode ser feita por meio da visão textual mas é notoriamente mais rápido visualizar as regiões graficamente do que textualmente. Figura Interface gráfica do Maestro Editor.

33 1.7. Usabilidade A usabilidade é considerada como um conjunto de fatores de qualidade de uso de um produto, ou seja, da qualidade experimentada pelos usuários do sistema ou produto tecnológico. Um produto com alta usabilidade é um produto eficaz e eficiente, seguro, útil, fácil de aprender e fácil de se lembrar como se usa [Nielsen 1993, Preece et al. 2002]. Mais recentemente, e com a invenção e disseminação de novas tecnologias, o conjunto de fatores que determinam a qualidade de uso de um sistema tornou-se mais abrangente. Um sistema precisa não apenas ter alta usabilidade, mas também ser satisfatório, agradável, divertido, interessante, motivador, esteticamente apreciável, incentivador de criatividade e emocionalmente adequados [Preece et al. 2002]. Esta seção apresenta um conjunto de diretrizes para o projeto de interfaces de usuário em geral e para TV Digital em particular. É importante observar, no entanto, que não basta apenas aplicar essas diretrizes para projetar um programa audiovisual interativo de alta qualidade. Para isto, é essencial seguir um processo de design iterativo e realizar avaliações junto aos telespectadores Diretrizes para o design de software interativo em geral A partir da análise dos objetivos e necessidades dos usuários, o produto é continuamente projetado, avaliado, reprojetado e reavaliado. Para auxiliar o processo de design, com freqüência são seguidos diretrizes e padrões de projeto de interface de usuário. Dentre as diretrizes mais utilizadas, destacam-se as relacionadas aos seguintes aspectos [Nielsen 1993, Shneiderman 1998, Tognazzini online]: consistência e padronização; uso adequado de terminologia e imagens; informações relevantes visíveis e atualizadas; feedback informativo e no tempo certo; possibilidades de ação e navegação claras e visíveis; atalhos e meios de interação eficientes, em particular para usuários freqüentes; meios de prevenção e tratamento de erros; reversibilidade de ações; seqüências de ações familiares aos usuários e completas ; controle e liberdade do usuário; redução da memória de curto prazo; uso de valores default; legibilidade; considerações com usuários com deficiências. Consistência e padronização. Existem diversas formas de consistência: terminologia utilizada em menus, títulos e telas de ajuda; seqüências de ações necessárias para situações semelhantes; posicionamento e tamanho dos elementos da tela; uso consistente de cores, letras maiúsculas, fontes etc. Deve-se ainda manter a consistência com as expectativas dos usuários sobre a apresentação de informações e o comportamento do produto. A inconsistência é também importante: elementos com comportamentos diferentes devem ser apresentados de forma diferenciada. Uso adequado de terminologia e imagens; informacões visíveis e atualizadas. Os textos e imagens utilizados devem ser facilmente compreendidos e reconhecidos pelos usuários. Deve-se evitar termos técnicos ou jargão, a menos que o produto seja dedicado exclusivamente a usuários especializados num determinado domínio. Além disso, os projetistas devem estar atentos a variações culturais na população dos usuários, que influenciam na sua compreensão de termos e imagens. Os termos, imagens e outros elementos da interface de usuário devem não apenas ser familiares aos usuários, mas também estar relacionados à tarefa corrente. Por mais que a equipe de projeto discuta sobre essas questões, é imprescindível que se façam estudos junto aos usuários.

34 Feedback informativo e no tempo certo. Para cada ação do usuário, deve haver um feedback do sistema. Para ações atômicas e freqüentes, a resposta pode ser sutil, ao passo que para ações infreqüentes ou muito importantes, a resposta pode ser mais substancial. Diferenças na aparência dos objetos de interesse oferecem um meio conveniente para mostrar as mudanças de forma explícita. Possibilidades de ação e navegação claras e visíveis. Qualquer produto interativo deve deixar claro onde o usuário está, como ele chegou lá, para onde ele pode ir, o que ele pode fazer e como. Atalhos e meios de interação eficientes; uso de valores default. Na medida em que a freqüência de uso aumenta, os usuários tendem a querer reduzir o número de ações e aumentar o ritmo da interação. Atalhos, teclas especiais, comandos ocultos e facilidades de customização costumam ser bem-vindos aos usuários freqüentes e conhecedores do produto. Meios de prevenção e tratamento de erros. Tanto quanto possível, deve-se projetar o sistema para que os usuários não possam cometer erros graves. Se os usuários cometem um erro, o sistema deve detectar o erro e oferecer instruções simples, construtivas e específicas para ele se recuperar do erro. Ações com erro devem manter o estado do sistema inalterado, ou o sistema deve fornecer instruções como restaurar o estado anterior ao erro. Reversibilidade de ações. Tanto quanto possível, as ações devem ser reversíveis. Isto motiva a exploração de opções que não são familiares para o usuário, e possibilita o aprendizado por tentativa-e-erro, visto que o usuário sabe que erros podem ser desfeitos. Deve-se decidir qual é a unidade de reversão: uma ação (cada letra digitada) ou um grupo de ações como o preenchimento de um campo de formulário. Seqüências de ações familiares aos usuários e completas. As seqüências de ações devem ser organizadas em grupos com um início, meio e fim, tão próximos quanto possível das expectativas dos usuários. O feedback informativo na conclusão de um grupo de ações dá aos usuários a satisfação de terem atingido um objetivo e é uma indicação clara de que já podem prosseguir para o próximo grupo de ações. Controle e liberdade do usuário. Os usuários experientes desejam sentir que estão no controle do sistema, e que o sistema reage às suas ações. Deve-se evitar ações do sistema que surpreendam os usuários, exijam dele um comportamento tedioso ou impeçam que ele obtenha as informações necessárias ou produza a ação desejada. Redução da memória de curto prazo. A limitação do processamento humano de informação requer que não se exija que os usuários se lembrem de muitas informações entre telas ou de vários passos para completar uma tarefa. Uma regra é que as pessoas podem se lembrar de sete mais ou menos dois pacotes de informação. Legibilidade. Os textos devem ser apresentados com contraste alto. Utilize tamanhos de fonte que sejam grandes o suficiente para serem lidos em monitores de diferentes tamanhos e resoluções. Privilegie o tamanho e apresentação das informações, em vez dos rótulos e instruções. Isto é particularmente importante no caso de números, pois os usuários precisam conseguir enxergar bem cada algarismo. Considerações com usuários com deficiências. Considere as pessoas com deficiências. O uso de cores e tamanho das fontes não devem impedir que pessoas com

35 vista cansada ou certos graus de deficiência visual utilizem o sistema. Analogamente, nenhum feedback importante deve possuir apenas um componente sonoro, pois prejudica os usuários com deficiência auditiva Aplicação de diretrizes para o design de programas de TV Digital Interativa Esta seção oferece diretrizes específicas para o design de programas de TV Digital interativa e exemplifica a aplicação das diretrizes genéricas no contexto de elementos desses programas. Tela As regiões da tela devem ser definidas de forma consistente em todo o programa. Logomarcas, títulos e barras de menu ou navegação devem ser posicionados, preferencialmente, em regiões fixas da tela, para que o usuário identifique rapidamente onde ele está e o que ele pode fazer em seguida. Os elementos pouco utilizados devem ser movidos para teclas secundárias (progressive disclosure). No padrão PAL, a resolução da TV é de 720x576 pixels. Mas como os televisores podem ter margens variantes, a BBC adota uma região segura com uma margem de 90px na horizontal e 50px na vertical, fora da qual nenhum conteúdo importante deve ser exibido [BBCi 2002]. Texto Apresentar texto na tela da televisão requer cuidados. A família de fonte utilizada deve ser adequada para a TV, como a fonte Tiresias, projetada especificamente para a TV. Outras famílias de fontes também vêm sendo utilizadas para exibir texto de legendas na tela, como Univers 45 e Antique Olive 6. Outras famílias de fontes podem ser utilizadas, mas deve-se prestar especial atenção à distinção entre algumas letras, que podem causar confusão para pessoas com e sem deficiência visual (e.g. I maiúsculo, l minúsculo e número 1; números 6, 8 e 9). Deve-se lembrar ainda que pode haver distorções no texto, caso o programa seja apresentado em proporções diferentes da original (mudanças entre as proporções 4:3 e 16:9). A BBC estabeleceu algumas diretrizes para o uso de texto em seus programas para TV Digital [BBCi 2002]. O tamanho da fonte utilizada no corpo de texto deve ser de pelo menos 24pt. Caso isso não seja possível, o tamanho não deve, em qualquer circunstância, ser menor do que 18pt. O texto claro sobre o fundo escuro é melhor de se ler na tela do que o contrário. Além disso, o texto na tela deve ter maior espacejamento entre linhas (e, se possível, entre letras) do que o texto impresso. Como regra geral, a BBC propõe ainda que uma tela inteira de texto não contenha mais do que 90 palavras, e que o texto seja quebrado em pequenos blocos que possam ser lidos rapidamente. Imagens Um pixel na televisão é ligeiramente retangular. Como um pixel em monitores de computador são quadrados, para se elaborar uma imagem no computador que será exibida na televisão, deve-se defini-la para o tamanho 768x576px e, para prepará-la 6 (último acesso em setembro de 2006)

36 para transmissão televisiva, deve-se reduzi-la horizontalmente (com distorção) para 720x576px [BBCi 2002]. Além disto, devido a diferenças na varredura das linhas na TV e no computador, deve-se evitar mudanças bruscas de cores no eixo vertical. Navegação e Controle Com relação a questões de navegação entre telas, valem recomendações para sistemas computacionais em geral. O telespectador deve ser mantido sempre informado sobre onde ele está, como ele chegou ali, e para onde ele poderá ir em seguida. Além disso, os mecanismos de controle e navegação devem ser consistentes e previsíveis. Com relação a comandos e ações, toda vez que o telespectador executar um comando, ofereça feedback imediato. Se o feedback de um comando levar mais do que 8 segundos para ser emitido, o telespectador provavelmente mudará de programa ou canal. Além disso, o telespectador não pode perder mais do que alguns segundos aprendendo a utilizar o programa ou serviço. Deve-se fornecer formas rápidas de saída do serviço ou programa corrente, bem como permitir que o usuário ative rapidamente o vídeo de tela inteira. Uso das teclas do controle remoto Apesar de não serem padronizados, os controles remotos costumam ter conjuntos comuns de teclas: controles tradicionais de televisão (ligar/desligar, mudar de canal, ajustar o volume); teclas numéricas (de 0 a 9); teclas de setas (,, e ) e de ativação (OK ou Enter); e teclas coloridas (geralmente vermelha, verde, amarela e azul). Alguns controles remotos possuem conjuntos específicos de teclas (e.g. teclas de paginação do tipo PgUp e PgDn). No entanto, como ainda não há um padrão adotado universalmente, o uso dessas teclas deve ser evitado. Teclas numéricas. Caso as teclas numéricas sejam utilizadas para digitar números com mais do que um algarismo (e.g. uma seleção dentre mais do que 10 opções numeradas), deve-se dar feedback imediato a cada pressionamento de tecla, indicando o número digitado até então. Além disto, deve-se oferecer também uma forma de corrigir o que foi teclado antes. Teclas de setas (,, e ) e de ativação (OK ou Enter). Pode-se optar por deixar o uso das teclas de setas em menus implícito (Figura 1.11a) ou representar explicitamente através de símbolos triangulares (Figura 1.11b). Menus cuja seleção é realizada através de setas podem ser circulares, ou seja, ao pressionar a seta para cima no primeiro elemento, a seleção passa para o último elemento, e vice-versa. (a) (b) (c) Figura Menus verticais (a) sem e (b) com indicação do uso das teclas de setas, e (c) trecho de tela com paginação.

Exibir mais