PIMA/MORE (Interface Adapt´ avel)

Bergman et al. (2002) constru´ıram o pima (Modelo Independente de Plataforma para Aplica¸c˜oes) para ser um sistema de modelagem e gera¸c˜ao autom´atica de interfaces multi- dispositivos baseado em modelo. Nessa forma de design, a especifica¸c˜ao das interfaces ´e feita atrav´es da constru¸c˜ao de um modelo declarativo abstrato sobre como a interface deve se comportar em diferentes contextos e dispositivos para s´o ent˜ao gerar automaticamente as interfaces concretas. Al´em disso, duas outras funcionalidades foram implementadas no pima (BANAVAR et al., 2004): customiza¸c˜ao manual das aplica¸c˜oes geradas, podendo-se usar o pima ou qualquer outro editor; e gera¸c˜ao autom´atica dos modelos declarativos gen´ericos a partir de aplica¸c˜oes HTML existentes.

A constru¸c˜ao de modelos abstratos gen´ericos a partir de aplica¸c˜oes visuais foi o re- sultado do trabalho de Gaeremynck et al. (2003) no desenvolvimento do more, uma fer- ramenta interativa baseada em regras extens´ıveis para inferˆencia de modelos em p´aginas web. Segundo eles, uma das grandes barreiras para o desenvolvimento de aplica¸c˜oes multi- dispositivos ´e a necessidade de treinamento em novas ferramentas de design que n˜ao lidam com objetos concretos de interfaces, tornando-se um desafio extra aos desenvolvedores. Al´em disso, essas abordagens s´o funcionam em aplica¸c˜oes desenvolvidas desde o come¸co, fazendo com que todas as demais tenham de ser reconstru´ıdas. Com a implementa¸c˜ao do

more acoplado ao framework pima, tem-se um ambiente de desenvolvimento capaz de extrair o modelo abstrato presente nas interfaces para constru¸c˜ao de um modelo gen´erico multi-dispositivo. Abordagens similares ao more j´a foram implementadas por ferramen- tas de engenharia reversa capazes de traduzir p´aginas web em representa¸c˜oes baseadas em modelo (BOUILLON et al., 2002) ou em modelos de tarefas (PAGANELLI; PATERN `O, 2002). A constru¸c˜<sub>ao do pima adotou novas concep¸c˜oes quanto `a compreens˜ao dos pap´eis</sub> desempenhados pelos dispositivos, aplica¸c˜oes e ambientes para a computa¸c˜ao pervasiva. Segundo Banavar et al. (2000), esses elementos podem ser resumidos nos seguintes pre- ceitos:

1. Um dispositivo ´e um portal dentro do espa¸co de uma aplica¸c˜ao e n˜ao um reposit´orio de software customizado e gerenciado pelo usu´ario;

2. Uma aplica¸c˜ao ´e o meio pelo qual o usu´ario realiza uma tarefa e n˜ao uma parte do software escrita para explorar as capacidades do dispositivo;

3. O ambiente computacional ´e a informa¸c˜ao do usu´ario (arredores f´ısicos aprimorados) e n˜ao um espa¸co virtual para armazenar e rodar um software.

A proposta dessa tese se aproxima destes preceitos (particularmente, os numerados por 2 e 3) por redirecionar a preocupa¸c˜ao do design `as tarefas e contexto do usu´ario ao inv´es das limita¸c˜oes dos diversos dispositivos. No entanto, embora tenha sido constru´ıda sob essas diretivas, a solu¸c˜ao fornecida por Banavar et al. (2004) parece priorizar mais o esfor¸co do designer do que o do usu´ario ao dar maior enfoque `a gera¸c˜ao autom´atica das interfaces. Essa impress˜ao fica clara na maioria das propostas de interfaces adapt´aveis, como ser´a apresentado nas subse¸c˜_{oes a seguir. Particularmente, para o pima, alguns} inconvenientes resultantes desse fato podem ser verificados em seus exemplos de telas geradas automaticamente para uma aplica¸c˜ao de com´ercio eletrˆonico (ver Figura 3.5).

Como se pode perceber, as interfaces da Figura 3.5a e 3.5b s˜ao muito parecidas por serem ambas direcionadas para uso em um mesmo dispositivo, possivelmente um desktop ou PDA. Logo, o modelo mental desenvolvido pelo usu´ario durante a intera¸c˜ao com uma delas poder´a ser reaproveitado. Por outro lado, a interface das Figuras 3.5c 3.5d e 3.5e mostram que o layout original teve de ser quebrado em algumas telas para se adequar `

as limita¸c˜oes de espa¸co do visor de um celular. N˜ao h´a d´uvidas de que manter o mesmo layout seria invi´avel ou mesmo imposs´ıvel considerando-se as limita¸c˜oes tecnol´ogicas de um interpretador de p´aginas WML. No entanto, o procedimento de adapta¸c˜ao autom´atica gerou pelo menos dois problemas:

• Inconsistˆencia de ativa¸c˜ao na barra de menu: Em geral, as aplica¸c˜oes para celulares podem usar uma barra de menu na regi˜ao inferior de seu visor com dois itens de

Figura 3.5: Exemplo de telas geradas pelo pima para uma aplica¸c˜ao de com´ercio eletrˆonico acessada em (a) um navegador web, (b) uma aplica¸c˜ao desktop ou (c,d,e) num celular (BANAVAR et al., 2004, p.233). Por serem destinadas ao mesmo dispositivo, as interfaces de (a) e (b) s˜ao muito parecidas, n˜ao revelando a necessidade de qualquer tipo de adapta¸c˜ao em alto n´ıvel. Por outro lado, as telas de (c), (d) e (e) mostram que a adequa¸c˜ao `as telas pequenas de celulares exige uma reestrutura¸c˜ao da interface original.

ativa¸c˜ao: um `a esquerda e outra `a direita. Por exemplo, a tela da Figura 3.5c disponibiliza um item de menu e a da Figura 3.5d disponibiliza dois. No entanto, os itens de menu da Figura 3.5d n˜ao quebram essa semˆantica de ativa¸c˜ao (“Menu” d´a acesso ao menu da aplica¸c˜ao e “alpha” habilita o cursor para inser¸c˜ao de caracteres alfa-num´ericos), o que n˜ao ocorre com o item “BrowseOrder” da Figura 3.5c. Como o nome desse item representa exatamente o que o usu´ario est´a fazendo na tela da Figura 3.5c (navegando pelos itens do seu pedido), acredita-se que essa op¸c˜ao de menu consiste apenas na informa¸c˜ao da tarefa sendo realizada, violando a premissa de que ele pode ser ativado. Ao contr´ario disso, o comportamento esperado do gerador de interfaces seria a substitui¸c˜ao desse item passivo pelo ativo de retorno ao menu da aplica¸c˜ao (como na tela da Figura 3.5d);

• Inconsistˆencia semˆantica no menu da aplica¸c˜ao: Com a redu¸c˜ao da ´area de vis˜ao do celular, a lista de itens do pedido (Figura 3.5c) n˜ao pode ser vista em conjunto com os controles de ativa¸c˜ao para descrever, remover ou requisitar novos itens (Figura 3.5e). Enquanto isso era poss´ıvel nas interfaces de desktop/PDA (Figuras 3.5a e 3.5b), fazia

sentido o uso de bot˜oes com o texto “Descrever o item selecionado” ou “Remover o item selecionado” (“Describe Selected Item” e “Remove Selected Item”). No entanto, o gerador autom´atico desconhece a semˆantica entre os objetos e faz a transposi¸c˜ao direta, o que pode gerar d´uvidas na tela da Figura 3.5e.

Estes s˜ao apenas alguns exemplos de inconsistˆencia que poder˜ao ocorrer na maioria das abordagens de transforma¸c˜ao autom´atica. Resta saber se estas inconsistˆencias iriam efe- tivamente reduzir a usabilidade da aplica¸c˜ao quando comparada com outras abordagens, principalmente em contextos de uso alternado e migra¸c˜ao de tarefas.