eis a interface: SORAIA (completo)

[Célio Ishikawa <nassifudeu gmail com>]

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