O documento descreve um projeto que usa painéis digitais em ambientes públicos para exibir eventos e conteúdo da web de forma interativa. O projeto propõe um modelo de programação descentralizado e baseado em padrões web para fornecer uma experiência de comunicação que melhore o espaço físico das comunidades.

1. Coreografia de eventos Web em painéis para ambientes
comunitários
Marcio dos Santos Galli
User Experience Labs
Taboca Brasil
{mgalli}@taboca.com
Felipe Gomes
Engenharia de Software ICMC
Estudante Universidade de São Paulo
{felipe.gomes}@gmail.com
RESUMO
A crescente disponibilidade de pain´eis digitais oferece novas
oportunidades para apresenta¸c˜ao de eventos de conte´udo em
ambientes f´ısicos nas comunidades. Com as melhorias de
conectividade da Internet e a constante evolu¸c˜ao das tecno-
logias Web, novos desafios de intera¸c˜ao usu´ario-computador
podem ser explorados. Nesse contexto, o projeto foca nas
possibilidades de uso de padr˜oes e tecnologias Web, como
meio para comunica¸c˜ao e intera¸c˜ao de informa¸c˜oes em am-
bientes f´ısicos. Prop˜oe-se um modelo de programa¸c˜ao que
seja aberto, distribu´ıdo, e que reflita a natureza evolutiva da
Internet, evitando-se assim, o modelo centralizado de pro-
grama¸c˜ao tradicional como da televis˜ao. O projeto busca
oferecer uma experiˆencia de comunica¸c˜ao que relaciona even-
tos de informa¸c˜oes da Web, visando melhorias nos espa¸co
f´ısico das comunidades.
Palavras-chave
Web 2, feeds, social-aware, browsing, W3C, RSS, chore-
ography, social-based browsing, context-aware computing,
computa¸c˜ao pervasiva, computa¸c˜ao sens´ıvel ao contexto
1. INTRODUÇÃO
A utiliza¸c˜ao de pain´eis visuais ´e crescente em ambientes
p´ublicos como escolas, teminais de transporte, restaurantes,
entre outros. Observa-se que solu¸c˜oes espec´ıficas de software
s˜ao utilizadas para prover uma experiˆencia de apresenta¸c˜ao
visual de conte´udo em tempo real - seja este conte´udo pre-
sente no computador local, na intranet, ou mesmo remoto
na Web. Com o crescente investimento da ind´ustria de pai-
n´eis, como monitores de led ou LCD, existe uma redu¸c˜ao
de custos de monitores, e crescente melhoria em rela¸c˜ao a
qualidade em aspectos como resolu¸c˜ao, brilho, contraste e
at´e durabilidade de materiais. Hoje, a utiliza¸c˜ao de pain´eis
tipo led, permite uma efetiva experiˆencia apresenta¸c˜ao vi-
sual na luz do dia al´em de oferecer uma economia superior
de energia.
Este cen´ario cria oportunidades para novos paradigmas
de visualiza¸c˜ao e intera¸c˜ao entre usu´arios e sistemas em es-
pa¸cos f´ısicos. Este projeto foca em modelos onde pain´eis
possam fazer parte de ambientes f´ısicos em meios sociais,
e propr˜oe uma experiˆencia de comunica¸c˜ao que seja com-
pat´ıvel com o modelo da Web e que busque melhorias no
contexto social local. Em contradi¸c˜ao aos tradicionais siste-
mas de televis˜ao, que tem um programa¸c˜ao centralizada, o
projeto sugere cen´arios que promovem uma experiˆencia de
programa¸c˜ao distribu´ıda baseada em eventos da Web. Neste
sentido, busca-se refletir valores da Internet, tais como capa-
cidade de escolha e a disponibilidade de informa¸c˜oes, visando
beneficios sociais para a comunidade.
Um modelo de navega¸c˜ao social ´e proposto, tal que usu´a-
rios e sites possam criar uma experiˆencia de visualiza¸c˜ao e
intera¸c˜ao com o conte´udo online, e que esta experiˆencia sirva
de suporte construtivo em ambientes sociais. O cen´ario atual
do projeto prop˜oe um sistema que baseia-se em tecnologia
de navega¸c˜ao Web que apresenta uma experiˆencia de acesso
e intera¸c˜ao Web para paineis do tipo LED TV. O projeto
tem o int´uito criar oportunidades para a explora¸c˜ao de para-
digmas intera¸c˜ao entre os usu´arios do sistema, sejam eles os
locais que est˜ao no contexto do espa¸co f´ısico, ou os usu´arios
remotos e sistemas Web que disponibilizam as informa¸c˜oes.
2. PROJETO NAVEGADOR SOCIAL
Esta sess˜ao apresenta a arquitetura geral do projeto. Em
linhas gerais, o termo navegador social ´e proposto como um
sistema que coordena a apresenta¸c˜ao de eventos de conte´udo
Web, dados cen´arios de interesse do meio local, com o ob-
jetivo de oferecer uma experiˆencia de programa¸c˜ao de con-
te´udo que seja descentralizada e visando benef´ıcios no con-
texto social.
web social ( o o o o o ( o o ) o o o o o ) social local
navegador social
Deste modo, busca-se oferecer uma experiˆencia que per-
mite a reutiliza¸c˜ao de recursos da Web, incorporando web
widgets [8] e conte´udo disponibilizado via RSS, e permitindo
que experiˆencias do tipo Mashup [4] possam ser criadas no
contexto de pain´eis, assim visando uma programa¸c˜ao mais
aberta e evolutiva. O modelo sugere tamb´em uma maior se-
para¸c˜ao entre os efeitos visuais de apresenta¸c˜ao, elementos
de conte´udo e web widgets, permitindo que usu´arios possam
definir cen´arios criativos de coreografia social.
Um prot´otipo, TagVisor ´e apresentado como uma aplica-
¸c˜ao baseada de Web standards, disponibilizada como soft-
ware aberto, baseada no Mozilla [5] XULRunner [9]. Esta
aplica¸c˜ao oferece algumas funcionalidades encontradas em
leitores de conte´udo tipo feeds [2] e capacidades adicionais
tal que cen´arios de coreografia de eventos possam ser dispo-
nibilizados.
[ web input ] --> [ navegador social] -> [output
3. ASPECTOS DA INFRA-ESTRUTURA

2. 3.1 Toolkit de Interação Web
O componente aplica¸c˜ao do projeto incorpora aspectos de
navega¸c˜ao de um browser com funcionalidades de um leitor
e agregador de feeds. Esta aplica¸c˜ao tem base no c´odigo
Mozilla Firefox [?] e Mozilla XULRunner e ´e disponibili-
zado como uma extens˜ao para o Firefox. Neste documento,
o termo toolkit web representa a infra-estrutura v´arias tec-
nologias e funcionalidades oferecidas pelo browser e basea-
das em padr˜oes abertos Web, que permite a possibilidade de
acessar a informa¸c˜oes de conte´udo do tipo feeds ( RSS, JSON
) via protocolo HTTP al´em das capacidades de renderiza-
¸c˜ao de conte´udo Web que permitem que conte´udo definido
em padr˜oes como XHTML, SVG, CSS, DOM, PNG, OGG
possam ser apresentados. A figura 1 apresenta a arquitetura
Gecko, que ilustra uma pilha de suporte a tecnologias web.
O prot´otipo TagVisor situa-se em cima na camada de exten-
s˜ao ao navegador Firefox e assim utiliza de v´arias tecnologias
Web disponibilizadas por esta infra-estrutura.
Figura 1: Arquitetura Gecko em Camadas
3.2 Suporte Web Offline
Dada uma experiˆencia tradicional de navega¸c˜ao por um
usu´ario, existem fun¸c˜oes de persistˆencia de dados que per-
mitem uma experiˆencia rica de navega¸c˜ao que vai al´em de
uma ´unica sess˜ao. Como por exemplo, as fun¸c˜oes de hist´ori-
oco ou bookmarks permitem que um usu´ario possa revisitar
uma certa p´agina. Neste sentido, o HTML 5 estende o con-
ceito para o n´ıvel de aplica¸c˜oes, permitindo que sites possam
armazenar dados entre sess˜oes de utiliza¸c˜ao. Esta funciona-
lidade ´e definida pela especifica¸c˜ao Offline Webapps [6]. No
caso de uma aplica¸c˜ao do tipo Web Mail, o suporte offline
pode permitir que o usu´ario possa compor uma mensagem
nova, voltar ao inbox, ler outras mensagens, tudo isto mesmo
que a Internet esteja temporariamente fora do ar.
No contexto do projeto, uma infra-estrutura de API offline
´e importante pois permite a implementa¸c˜ao de algumas ca-
pacidades do sistema. Uma ´e que dados de conte´udo possam
ser agregados no contexto local da aplica¸c˜ao cliente, permi-
tindo uma posterior an´alise ou apresenta¸c˜ao visual. Outro
crit´erio, que garante qualidade do sistema, trata-se da ca-
pacidade de se manter referˆencia dos eventos de coreografia
de forma estruturada de tal forma que se a conex˜ao com a
Internet cair, o sistema mant´em uma experiˆencia de comuni-
ca¸c˜ao consistente. Existem outras capacidades que n˜ao est˜ao
inclu´ıdas na atual proposta, como manuten¸c˜ao de hist´orico
referˆente aos eventos do sistema.
4. CAPACIDADES E CENÁRIOS
4.1 Canais de Conteúdo e Eventos de Feed
Na navega¸c˜ao tradicional, controlada por um usu´ario, o
acesso as p´aginas representam eventos de entrada de con-
te´udo no contexto do browser. O usu´ario tem autonomia
para clicar em links e assim obter novos eventos de infor-
ma¸c˜ao. No escopo do navegador social, a proposta ´e que a
intera¸c˜ao com os recursos Web se fa¸ca indiretamente atrav´es
de eventos de conte´udo e n˜ao pela a¸c˜ao direta por usu´arios.
Para este fim, propr˜oe-se a utiliza¸c˜ao de feeds.
Em geral, sites de not´ıcias disponibilizam a cole¸c˜ao dos
´ultimos artigos via feeds, como RSS. Este modelo ´e bem
difundido e suportado por v´arios toolkits web ou frameworks
para renderiza¸c˜ao de conte´udo web.
Uma das capacidades propostas ´e que itens de feeds sejam
processados individualmente uma vez que o conte´udo de um
dado canal de feed ´e recuperado pelo sistema, tornando-se
eventos de feed que entram em uma fila no sistema. Estes
eventos ser˜ao posteriormente tratados por regras que defi-
nem rela¸c˜oes de coreografia no sistema.
A figura abaixo representa o modelo XML de um item de
feed exemplo e o parte do canal RSS de origem:
COLOCAR RSS ORIGEM NA FIGURA -
<feeditem:event id="0000001" domain="usp.br" path="/noticia">
Noticia , link
</feeditem>
Uma vez categorizados como eventos feeditem, estes ele-
mentos s˜ao mantidos no contexto da aplica¸c˜ao em uma para
processamento, de forma persistente gra¸cas a infra-estrutura
de suporte offline. Esta manuten¸c˜ao garante que os eventos
possam ser tratados posteriormente, mesmo em caso que a
conex˜ao com a Internet se perca.
4.2 Regras de Coreografia
Um modelo de sintaxe similar ao CSS permite que regras
de filtro sejam aplicadas aos itens de feed, permitindo uma
contextualiza¸c˜ao de conjunto de itens de feed, como eventos
no sistema, denominados eventos de contexto. Em um exem-
plo de cen´ario, existem elementos de feed inicialmente dispo-
nibilizados por dois canais de RSS, sites www.slashdot.org
e www.w3.org. Neste exemplo, o objetivo ´e de se criar um
evento de contexto denominado artigos que une tanto os
itens de feed do slashdot como w3 em um mesmo contexto,
permitindo que estes possam ser processados posteriormente
por um component Web.
No modelo CSS, a sintaxe geral segue o formato:
selector {property: value}
No modelo proposto, a func˜ao do seletor ´e similar ao CSS,
permitindo que itens de feed sejam selecionados uma vez que
estes est˜ao dispon´ıveis em um reposit´orio tipo ´arvore DOM.
Deste modo ´e poss´ıvel a especifica¸c˜ao de regras de filtro que
referem-se a um conjunto de elemento e suas restri¸c˜oes. Uma

3. diferen¸ca em rela¸c˜ao ao modelo CSS, ´e que o contexto de
opera¸c˜ao property-value permite que o evento de contexto
seja criados, al´em de poss´ıveis atribui¸c˜oes ao elemento se-
lecionado. O c´odigo exemplo a seguir refere-se ao exemplo
onde o conte´udo dos sites ´e agrupado em um mesmo evento.
feedevent | * [domain="www.slashdot.com"] {
-context-event: artigo;
}
feedevent | * [domain="www.w3.org"] [path^="/menu"] {
-context-event: artigo;
}
Desta maneira, toda vez que um evento de feed entra na
fila de processamento, as regras de contexto s˜ao executadas
e poder˜ao gerar eventos de contexto caso regras sejam satis-
feitas. No caso do exemplo, para cada ocorrˆencia do evento
de contexto artigo, um observador componente Web poder´a
receber a notifica¸c˜ao e referˆencia para os elementos relacio-
nados, o que permitir´a uma a¸c˜ao de intera¸c˜ao no sistema de
sa´ıda.
4.3 Composição com Eventos de Contexto
Uma das capacidades do projeto ´e que seja poss´ıvel o ge-
renciamento de relacionamentos e opera¸c˜oes com eventos.
Um estado de composi¸c˜ao ´e uma abstra¸c˜ao que identifica
um evento de contexto que existe e se relaciona com outros
eventos de contexto. Posteriormente, estes estados ser˜ao
utilizados para se criar a¸c˜oes no contexto dos componentes
Web permitindo-se uma apresenta¸c˜ao e efeitos visuais.
Um modelo de composicao [3] permite descrever relacio-
namentos entre os eventos que ocorrem em uma sess˜ao. A
´arvore abaixo define uma composi¸c˜ao onde o evento estado
zoom no menu ´e ativado porque existiram relacionamentos
entre estados de contexto anteriormente. Os elementos sem
marca¸c˜ao s˜ao eventos de contexto gerados a partir de regras
de coreografia aplicadas a itens de feed. Os elementos mar-
cados com ”:and”tratam-se de contextos de relacionamento.
Neste caso, and, significando que a existˆencia do contexto s´o
´e v´alida caso todos os eventos de contexto imediatamentre
associados existam.
[zoom_menu:and]
/
/
/
[apresentar-menu:and] [meio_dia]
/
/
[lunch-menu] [onzehoras]
Neste modelo, a opera¸c˜ao de contexto and tamb´em pode
ser descrita por regras de coreografia. Note que o evento de
contexto que refere-se aos seletores contextevent|lunchmenu
e contextevent|onzehoras ´e definido como -context-event-and.
contextevent | lunch-menu, contextevent | onzehoras {
-context-event-and: apresentar-menu;
}
Neste caso trata-se de uma opera¸c˜ao do tipo ”and”que
define que o evento estado de contexto apresentar-menu s´o
existir´a ap´os os eventos de contexto lunch-menu e onze-horas
ocorrerem. Caso o evento de contexto lunch-menu ocor-
rer antes da existˆencia de onze-horas, ´e proposto que um
pseudo-evento do tipo context-event seja insiderido no sis-
tema com a referˆencia apresentar-menu. Este estado pseudo-
evento s´o vai se transformar em evento de contexto real,
apresentar-menu, quando todos os os eventos de contexto
dos seletores que definem a regra AND existirem. No caso,
depois que o onze-horas tamb´em ocorrer.
Este modelo permite que constru¸c˜oes de relacionamento
possam ser criadas com uma performance boa pois os esta-
dos podem ocorrer naturalmente, mesmo que no contexto
pseudo, at´e que a valida¸c˜ao da opera¸c˜ao do estado, ope-
ra¸c˜ao AND no caso, seja cumprida, o que recategoriza o
pseudo-estado como estado, tornando-o ativo no sistema e
implicando que outras rea¸c˜oes na cadeia de estados possam
acontecer.
No contexto de implementa¸c˜ao, estes eventos de contexto
de relacionamento podem ser criados utilizando-se de Selec-
tors API [7], que oferece suporte para a utiliza¸c˜ao de se-
lectores para se obter um conjunto de elementos dado um
documento DOM. Uma estrutura de dados tipo hash ´e pro-
posta para se manter um objeto ”apresentar-menu”que tem
referencia para os contextos esperados ”lunch-menu”e ”onze-
horas”
pseudoEvent["apresentar-menu"] = {
"lunch-menu" : contextEvents["lunch-menu"],
"onze-horas" : contextEvents["onze-horas"]
};
contextOperationObject["apresentar-menu"] = {
this.contextResult : true,
iterate: function (contextEvent) {
this.contextResult = contextEvent && this.contextResult;
}
finalization: function() {
return this.contextResult;
}
}
5. REFERÊNCIAS
[1] D. H. Dean Jackson and C. Marrin. Css transitions
module level 3 (working draft). Technical report,
W3C, March 2009.
[2] Web feeds. http://en.wikipedia.org/wiki/Webfeed.
[3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Design Patterns, section 4, pages 163–166.
Addison-Wesley, Boston, MA, January 1995.
[4] Mashup - web application hybrid.
http://en.wikipedia.org/wiki/Mashup (web application hybrid).
[5] Projeto mozilla. http://www.mozilla.org.
[6] Offline web applications.
http://www.w3.org/TR/offline-webapps/.
[7] A. van Kesteren and L. Hunt. Selectors api (working
draft). Technical report, W3C, November 2008.
[8] Widgets web.
http://en.wikipedia.org/wiki/Web widget.
[9] Mozilla xulrunner.
https://wiki.mozilla.org/Xulrunner.
[10] T. ¸Celik, E. J. Etemad, D. Glazman, I. Hickson,
P. Linss, and J. Williams. Selectors level 3 (working
draft). Technical report, W3C, March 2009.