ubuntu-br-sp team mailing list archive

[Célio Ishikawa <nassifudeu@xxxxxxxxx>]

Meus caros, talvez tenha ido sem querer um rascunho incompleto um par de
horas atrás.
Pois bem, agora tá completo e se acharem muito grande, os tópicos *Exemplo
prático simples,* *Exemplo prático complexo,* e *Por que é diferente da
computação atual?* mostrarão as principais idéias.

Agradeçido,
Célio/ zuka



SORAIA - Sistema de Operações baseada e Realidade Aumentada e Interface
Alternativa

*preâmbulo:
O paradigma da Realidade Aumentada*

A tecnologia da Realidade Aumentada consiste em mostrar um marcador para o
computador, como por uma WebCam e o computador receber esses dados e
projetar algo novo na tela ou no óculos virtual. (há exemplos como esse:
http://www.youtube.com/watch?v=6Eohr1mmRTo) Temos assim uma nova forma de
entrada de dados e de saída. A enrtada de dados ocorreu por meios como
pedaços de papel para o computador interpretar. O fato desse movimento da
entrada de dados não ter ocorrido diretamente a partir de bits foi um
detalhe crucial nas relfexões para desenvolver a nova interface. Com o
avanço da tecnologia é previsível que a RA (Realidade Aumentada) aceite
marcadores menos óbvios. Imaginamos que no futuro uma folha de texto será
entendida pelo computador sem precisar de marcador ou com um marcador muito
discreto e pequeno num canto, como um carimbo.

Achamos que o poder da webcam se aproximará do de um scanner. Como scanners
são poderosos por passarem uma luz no papel, enquanto que webcams capturam a
imagem de imediato, pode ser que soluções mistas* surjam, por exemplo de
pontar com dedo um pedaço do papel onde uma luz similar ao scanner vai
passar. Ou seja, a webcam acompanha o dedo, e no local apontado um
reconhecedor de imagens/caracteres mais poderoso captura os detalhes que a
webcam não é capaz de capturar. Scanners reconhecem imagens e caracteres,
mas apenas de forma passiva, colocando a foto ou texto para serem editadas,
mas é bem diferente da RA, quando a imagem capturada desencadeia uma série
de respostas de forma que haja interação em tempo real com o usuário.

Quanto à saída, à projeção de dados, pensar apenas na tela do monitor
significa ignorar tecnologias de projeção em superfícies (
http://www.youtube.com/watch?v=40tS8A-SJ6c), ou de óculos virtuais (
http://www.youtube.com/watch?v=arYdn-05YcM), dois casos em que os dados
aparecem fora do monitor. Não entendam essas possibilidades apenas como
saída de dados, é de se ressaltar como elas são interativas (mesmo quando é
apenas um laser sobre uma superfície
http://www.youtube.com/watch?v=HP1uOXIJUm4) ou seja, simultaneamente enviam
o dado e recebem de volta a imagem da interação do dado projetado com o
usuário que motiva a enviar mudanças do dado projetado como resposta.


*Exemplo prático simples:*
Pegue um papel e coloque na frente do computador. Ele irá reconhecer
imediatamente o texto. Você vai passar o dedo sobre as palavras que
precisará corrigir e riscos à laser vão ser projetados sobre as palavras,
como se você estivesse riscando-as. Ou, imagine que no papel tem um desenho
de um copo. Colocando o dedo sobre o desenho de um botão, uma animação é
projetada sobre o papel como se o copo estivesse sendo preenchido com água.


*Para além do RA: interface alternativa:*
Alguns de vocês podem ter comentado que já viram isso mas sem ser em RA, mas
sim na interação através de touchscreen de tablets e e-papers que logo
imundarão o mercado. Por essa razão é que percebemos que não estávamos
diante apenas de modelos de RA, a força da nossa proposta estava na forma de
interagir e no sistema de operações para viabilizá-la. Ao verem o exemplo
complexo vocês entenderão a necessidade disso:


*Exemplo prático complexo:
*Temos um papel com texto. A pessoa pega um outro papel com linhas e
colunas. Ela coloca a mão sobre o texto e arrasta os dados para o papel com
tabela. Apenas os dados relevantes foram movidos, e no outro papel agora
temos tabelas com os dados organizados. Se a pessoa aprovou, os dados não
precisam ficar apenas na projeção, um braço de impressora pode se estender*
e imprimir os dados para ficarem permanentes e serem passados para outra
pessoa
Ou temos um papel com desenho de um tubo de ensaio. O cientista faz o
desenho de um fogo embaixo do tubo e o uma animação indica que o liquido
dentro do tudo começa a borbulhar. O cientista faz outro desenho, uma flecha
para cima e escreve 100°C. Agora no papel temos a simulação de um líquido a
100°C. Ele arrasta aquele conjunto de desenho/projeção sobre papel para
outro desenho representando outra substância. Foi uma simulação de reações
químicas. Dados são projetados (seja sobre o papel ou seja na tela do
e-paper) e ele arrasta esses dados para preencher um arquivo de texto ou de
tabela do exeplo anterior.


*Sistema de Operações *
No exemplo complexo, foi superada a idéia de arrastar elementos
decorativos/animados que é ainda o foco de muitas aplicações de RA e mesmo o
chamariz para o touchscreen. Não se trara apenas de arrastar caracteres e
imagens, se trata de arrastar dados complexos para que o receptor às
decodifique e use à sua maneira.


*Mais que clipboard:*
Pensemos no cotidiano: quando uma pessoa quer copiar dados da internet para
o processador de texto, às vezes ela quer copiar a formatação do site e às
vezes não quer. No Firefox por exemplo um complemento chamado CopyPlainText
oferece esta última opção. De forma que no cotidiano às vezes deparamos com
níveis de complexidade nos dados que vão para o clipboard. Mas no nosso
modelo, o nível de complexidade dos dados é muito maior, se trata de
arrastar a palavra (ou desenho) "água" e o programa receptor não entendê-la
apenas como 5 letras mas como elemento água para química. E mais: o
clipboard copia apenas o que está visível, o que o programa que enviou dados
entende. No nosso modelo queremos que arrastar uma pedra (palavra ou
desenho) e o programa receptor seja um decodificador de seus elementos
químicos. Pensemos mais: cada folha de papel acaba se tornando um
instrumento de laboratório de forma que com RA ou e-paper um punhado de
páginas possa ser um laboratório portátil levado pelo cientista. Queremos
que ao arrastar de um canto ao outro o objeto de pesquisa, eles carreguem
consigo um histórico que interesse ao programa receptor. De forma que ao
arrastar um líquido, ele está arrastando junto a temperatura a que foi
submetida, misturas, e talvez até mesmo variações na força gravitacional
(coisas que o mundo virtual pode simular).


*Escalonamento de complexidade no clipboard e retroescalonamento:*
Os dados quando copiados/recortados têm um nível baixo de complexidade, por
exemplo, inicialmente é entendido apenas como caracteres ASCII. Mas no
programa seguinte, é entendido como uma palavra associada a outras palavras,
quando for para organizar em tabelas. No outro, a palavra é entendida pelo
seu significado, como se houvesse um dicionário embutido. E no simulador de
reações químicas, recebe manipulações, de forma que o dado a ser colado
carrega em si a informação de que se trata de caracteres ASCII, relevância
da palavra, significado e histórico manipulações. Quando submetida a um
outro programa que simule pressão e passagem de tempo, há tranformação do
elemento químico en outra coisa.

OK, obtendo novo elemento, hora de colocar os resultados em forma de tabelas
e texto. Aí acontece um retroescalonamento na complecidade de dados. No
simulador de reações químicas, obviamente é tratado como outro elemento. Na
tabela, a tebela entende que ela mudou de relevância e muda seu lugar. No
dicionário um outro verbete é chamado e por fim no texto, é colocado de
forma que as outras palavras-chave entrem em concordância. Por exemplo, se X
era maior que Y e agora não é mais, o texto cuida de arrumar isso. E esse
movimento não precisa ser apenas de uma palavra: um conjunto de dados pode
ir para a tabela e da tabela ao texto, arrumar várias partes do texto (tal
como hoje, a arrumação pode não ser completa mas por sublinhamento de itens
como nos coretores ortográficos).

Nesse movimento, tanto no início quanto no fim o processador de texto não
teve de lidar com a complexidade de entender elementos químicos, já que isso
explodiria a capacidade do programa. Por outro lado, o simulador de pressão
e tempo já lida com dados mais que suficientes e não quer lidar com regras
de formatação de texto. De forma que entre os dois houve camadas de
programas que foram interpretando dados e assim lidaram com o escalonamento
e retroescalonamento da compleidade deles.


*Organização de arquivos e programas:*
Pela nossa proposta, os aquivos vão acumulando camadas de dados. Por
exemplo, um desenho de copo d'água vai recebendo uma camada de dados sobre
composição da água e do vidro, outra camada dados enciclopédicos, outra
camada as possiblidades de manipulação química, e assim por diante. Pelo
fato deles estarem sobre o desenho, de forma "flutuante" eles parecem ser
dados de clipboard. Digo "flutuante" pois não é que o dado e o desenho são
uma coisa só, já que o desenho no básico é entendido apenas como bitmap, e o
programa correspondente entende apenas como tal, Sendo assim, é como se um
recorte ficasse em cima do papel mas nunca fossem colado. As camadas são
como pedaços de papel ou coisas escritas em celofame e arranjadas sobre o
papel-base, mas não coladas com cola.

Essa forma de organização se lembra muito os arquivos que mexem com camadas,
como os do GIMP (Gnu Image Manipulation Program). Mas no Gimp é um arquivo
só com camadas que só ele entende. No nosso modelo, qualquer programa pode
ver o arquivo-base, mas o entendimento das camadas acompanhantes depende de
programa para programa. Assim as camadas não são clipboard, por elas
carregarem dados complexos é como se cada uma delas fosse um arquivo. Mas
como arquivos empilhados, como se fossem folhas com desenhos, textos,
tabelas e vários dados empilhados como folhas que formam uma revista.

Essa forma de organização se inspirou na observação de folhas de papel
mesmo, mas acrescentando níveis de interação muito maiores. Elas serão
folhas de e-paper ou folhas de papel mesmo com marcadores de RA em cantos e
projeção de dados sobre superfície.

Já os programas acompanham as páginas. É como se um texto, imagem acionasse
a abertura dos programas, ou uma virada da página virtual de um e-paper
tivesse o mesmo efeito de acionar. Pela proximidade muito grande com dados
sendo exibidos/arrastados, imediatamente elas estão manipulando o arquivo,
sendo por isso diferentes de programas que abrem e depois precisa ser aberto
o arquivo dentro delas. Mas se é um dado está sendo manipulado de um jeito
que aciona outra função, afinal é um outro programa que abre ou é um plug-in
que é acionado? Boa pergunta. Acreditamos que a barreira entre plug-in e
programa se tornará trêmula, afinal o arquivo estará lá, sua manipulação,
que pode ser o simples arrastar (ou desenhar fogo embaixo dela, ou escrever
o que fazer em cima dela, o que for) já aciona outra função, de forma que se
é o mesmo programa que aciona um plug-in para nova função ou deixa a tarefa
para outro programa, a diferença é pouca. Tradicionalmente para um outro
programa mexer um arquivo precisaria ser exportado para outro formato. Entre
programas de desenho e ilustração há vários programas de vários fabricantes.
E a incompatibilidade de formato impede um simples visulalizador de imagens
ver a imagem mesmo que ela só queira imprimir e não mexer em camadas,
vetores, etc. Exportação de arquivos ficará obsoleta, e será tão fácil criar
uma cópia arrastando que aas pessoas esquecerão o que é o "Salvar Como".

*
Por que é diferente da computação atual?*
Porque atualmente a idéia de camadas só existe para arquivos especiais e só
programas especiais abrem. Porque não é propriamente um arquivo com camadas,
tá mais para camadas de arquivos. Porque para guardar tipos de dados
diferentes, hoje se coloca vários arquivos de extenções diferentes numa
mesma pasta, e se nomeia a pasta de forma a organizar o tema comum àqueles
arquivos dentro da pasta. Mas não estamos falando de pastas/diretórios,
estamos falando de camadas de arquivos, mas não empilhadas de qualquer
forma, cada camada é como um pedaço de papel ou folha de celofane de forma
que a base nunca é ocultada. É um desenho de copo com várias camadas de
informações agregadas e não uma pasta chamada "copo" com arquivos tipo
imagens, textos e tabelas, etc dentro dela.

E se os tais livros eletrônicos já estão esboçando a centralização de
importância no conteúdo, de forma que o conteúdo contém uma série de links e
anotações que o expandem, eles ainda não organizaram a transferência de
dados com escalonamento e retroescalonamento. De forma que para passar os
dados, precisa ser do jeito manual recortar/copair/colar, ou
exportar/importar arquivo e os programas são janelas que esperam o arquivo
chegar. No nosso modelo, as funções chamam os programas tão rápido e sem
atrapalhar a visualização de outras camadas-arquivo que a idéia de uma
janela ficar na frente e tapar a outra pode ficar ultrapassada. A parte
visual desse modelo ainda deixamos em aberto, sendo assim janelas de
programas podem ou não existir, mas se existirem, faz mais sentido que elas
sejam semi-transparentes ou sejam apenas botões flutuantes, barras laterais
de forma a não tamparem outras camadas de dados. (Do contrário, ao abrir um
programa que vê a temperatura, só aparece a temperatura, e não o objeto, um
programa de esquentar a água tampa a quantidade de água que outro programa
adicionou, etc.)

Além do mais, por eles partirem de telas touchscreen que valem por várias
páginas, enquanto que nós pensamos em papéis sobre a mesa e
conteúdos/dados/tarefas sendo arrastados por eles, a principal forma de
transmissão que eles pensaram é o velho modelo de minimizar o arquivo,
mandando o arquivo-ícone para outra tela por wireless ou USB.

Atualmente minimizar, reduzir o conteúdo à ícones e guardar em pastas, abrir
em programas, copiar, colar, exportar, importar tem sido a forma das pessoas
trabalharem com manipulações de dados até mais complexas que os exemplos
dados aqui. Nós podemos dar mais dinamicidade à essas tarefas.


*System-centered. User-Centered... Labor-Centered?*
Até vai parecer que quero lugar na academia inventando um novo conceito, não
é isso, mas quando faltam explicações, o jeito é inventar um conceito novo.
Existe o conceito de System-Centered que é o desenho do sistema centrado no
sistema. Como contraponto surgiu o User-Centered que diz ser focado no
usuário. Quando Steve Jobs lançou o MacOsX disse orgulhoso dizendo que agora
o Finder é user-centered. Como disse, não almejo provar a
importância/relevância de um conceito novo, portanto narrarei a situação em
que os termos system-centered e user-centered não me satisfizeram.

Seja no antigo Finder, seja em outros gerenciadores de arquivos
system-centered, os arquivos que faziam os sistema funcionar eram os vistos
como importantes e esse modelo listava primeiro os drivers, diretórios e
arquivos do sistema. As pastas do usuário e seus arquivos pessoais eram
subdiretórios. Do ponto de vista do sistema, não faz sentido colocar o
desktop como topo acima do "Computador", mas é isso mesmo que ocorreu no
modelo user-centered. O desktop, os favoritos, o histórico e arquivos
gerados pelo usuário ganharam importância. Alguns arquivos do sistema até
passavam a ser invisíveis. O pendrive, quando espetado, mesmo sendo um
subdiretório montado dentro do sistema, aparece no desktop como abaixo
apenas do desktop.

Contudo, se o user-centered parece ser a última palavra, o defeito parece
ser justamente em ser focado demais para um usuário. Favoritos e Histórico
são coisas que só fazem sentido para o próprio usuário. Refletindo sobre RA,
nos pareceu que o principal objetivo da tecnologia é mostrar para o outro e
não para si mesmo. Quando pensamos nos exemplos que demos acima, pensamos em
cientistas fazendo coisas e anotando para outros cientistas verem. Inclusive
chegamos a pensar que uma evolução do RA podem ser dados sobre papel que
invocam outros dados nos computadores de forma que esse conjunto de
invocações possa substituir em parte a transmissão de dados via bits
eletrônicos (assim você fica menos frustrado do que quando perde um
pendrive!).

Transmissão para outro ver e interface focada no arquivo-camada-tarefa em
execução. Para o ususário entender (e complementar), para outro usuário
entender e até mesmo o computador entender por como transmissão de bists
não-eletrônicos. Por tudo isso o centro parece ser o labor. E o conjunto
forma um laboratório. De forma que pensamos na palavra labor-centered.


*Programação com caneta?
*Mostramos como funcionariam os programas. Como as pessoas podem colocar
sinais gráficos (RA) ou fazerem gestos que o computador entende (arrastar,
apertar, e talvez sejam desenvolvidos outros, como de juntar,
partir/separar, etc. Coisas que estão se esboçando com o multitouch).

Mas com isso as pessoas estão agindo conforme o script, usando as
funcionalidades que os programadores dos programas previram que seriam
usadas.

Como ousadia a mais, tentamos imaginar se o usuário não seria capaz de
escrever mini-programas de forma rápida com o aprendizado de regras simples
que não chegassem a ser linguagens de programação. E num cenário que talvez
seja até irreal (e não sabemos a viabilidade), os mini-programas seriam
escritos no papel e sem precisarem de computadores ligados. Aí através do
scanner os dados seriam imputados, compilados e tornados executáveis.

Voltemos ao exemplo do texto. Pensamos que o usuário poderia marcar as
palavras que um novo programa reconhecerá como importantes e arrumará em
conjuntos. Aí após marcá-los alguma coisa invocará que está sendo iniciada
uma programação (o que de repente se reduz a um sinal que a pessoa desenha
no canto da página). Desenhando balões, vai sendo formado conjunto de
palavras, elas podem ser para indicar sinônimo (troca de palavra por outra),
ou chamar outro arquivo (um desenho) ou ação. Flechas indicariam qual seria
o próximo passo, por exemplo de arrumar esses conjuntos em tabelas, e talvez
inserir um cálculo a ser feito associando váriáveis numéricas a elas.
Manipulações em RA são fantásticas. É possível fazer por exemplo com que um
sinal de mais desenhado pressionado (ou, do ponto de vista da webcam,
escondido com dedo) sirva para aumentar o volume. Podem surgir variações
como aumentar o volume depois de selecionado o desenho de volume e aumentar
a temperatura quando selecionado o desenho do termômetro.

Isso foi pensado imaginando um grupo de cientistas que fosse fazer uma
expedição e encontrasse um novo elemento e fosse fazendo experiênciaas e
anotando dados, mas quisesse eles mesmos criar um simulador de testes a ser
copiado para outros de forma que outros possam ter idéias das suas
propriedades sem terem a amostra do elemento. De posse de dados, um dos
cientistas que recebeu a cópia poderia combinar com outras camadas de
arquivos-programa (que outros não tinham talvez pela distância geográfica,
ou por ser um programa que ele escreveu sozinho) e assim obter novas
descobertas, virtualmente, para só depois precisar confirmar com materiais
de laboratório reais.

*Agradeço a todos que leram até o final*
Essas são as idéias básicas e daqui para frente será preparar exemplos
melhores e formas de apresentação.
* teve dois lugares que deixei asterisco, quanto à idéia de scanner
combinado com webcam e impressora também combinada com webcam, de forma que
respectivamente eles iriam escanear e imprimir onde o usuário apontasse com
dedo. No caso da impressora, isso traria o benefício do aproveitamento
melhor de papel já que espaços em branco seriam reconhecidos e talvez
pudessem ser inclusos erratas e observações nos cantos ao invés de formatar
e imprimir de novo, ecnomizando papel e tinta com isso. Pois bem é só para
comentar que esse tipo de ideia talve pudesse ser patenteado, mas não tenho
intenção disso pois fazem mais parte das preliminares do projeto, e além do
mais, patente de coisas assim, simples, atrapalhariam o próprio
desenvolvimento da tecnologia, além de possivelmente causar uma briga de
patentes pois vários fabricantes podem alegar que registraram algo parecido.
Quero mais é divulgar isso que desenvolvi protegendo a autoria sobre a ideia
e se possível trabalhar com isso no futuro.

Célio Ishikawa