CanonSketch: uma ferramenta para Prototipagem Abstracta e Desenho de Padrões de Interface

Transcrição

1 CanonSketch: uma ferramenta para Prototipagem Abstracta e Desenho de Padrões de Interface Pedro F. Campos Dep. de Matemática e Engenharias, Universidade da Madeira Campus da Penteada, Funchal pcampos@uma.pt Nuno J. Nunes Dep. de Matemática e Engenharias, Universidade da Madeira Campus da Penteada, Funchal njn@uma.pt Sumário Neste artigo, argumentamos que as ferramentas actuais de modelação de interfaces de utilizador não suportam o desenvolvimento moderno de software, visto serem desenvolvidas numa perspectiva centrada nos formalismos subjacentes, e não nas actividades do designer. Propomos então uma ferramenta CanonSketch que suporta a especificação de interfaces a vários níveis de abstracção, incluindo uma nova linguagem (Protótipos Abstractos Canónicos) que que preenche a lacuna que existe entre o comportamento esperado do utilizador (o modelo de tarefa) e a realização concreta da interface. Apresentamos uma extensão ao UML (usando o modelo Wisdom) que suporta a linguagem Canónica, o que permite adicionar uma semântica e uma precisão desejáveis a uma notação pragmática e informal. Investigamos as vantagens de uma ferramenta deste tipo na especificação de padrões abstractos de desenho de interfaces, e mostramos que a complementaridade entre as vistas do CanonSketch permite exprimir padrões a vários níveis de abstracção, o que é particularmente útil para padrões que apresentam problemas quando modelados numa ou noutra linguagem. Palavras-chave Prototipagem, Design de Interfaces, Padrões, Especificação de Interfaces, Modelos. 1. INTRODUÇÃO O desenho de interfaces seguindo uma abordagem baseada em modelos tem sido alvo de muita investigação durante a última década. Contudo, e apesar do sucesso obtido pelas ferramentas de desenvolvimento de interfaces com o utilizador (IU), as abordagens formais, basedas em modelos, não estão a atingir a maturidade industrial preconizada nos anos 90 [Myers00]. Num artigo apresentado e discutido numa Workshop recente sobre desenho de interfaces baseado em modelos [Nunes04], argumentámos que a fim de obter uma maior aceitação no mercado, terá que emergir uma nova geração de ferramentas de modelação e especificação de interfaces. Essa nova geração será constituída por ferramentas que suportem claramente as actividades de desenvolvimento, em vez de se centrarem nos formalismos semânticos necessários à geração automática de interfaces a partir dos modelos. Por outro lado, tem havido um crescente interesse na possibilidade de utilizar padrões [Alexander77] para a especificação, desenho, desenvolvimento e avaliação de IU [Welie00, Paternò00, Nunes03]. Os padrões nasceram a partir das ideias do arquitecto Christopher Alexander e foram sugeridos como uma forma de tentar capturar a experiência de desenho coleccionando, definindo e testando uma série de soluções empiricamente comprovadas como eficazes para problemas de desenho recorrentes [Gamma95]. Este artigo apresenta a ferramenta CanonSketch. O CanonSketch suporta uma nova linguagem de especificação de IU Protótipos Abstractos Canónicos (PAC) que preenche a lacuna que existe entre o comportamento esperado do utilizador (o modelo de tarefa) e a realização concreta da interface. Tentamos também explorar a importante questão de como podem os padrões de interface ser especificados, mantidos e testados por uma notação (i) suficientemente expressiva, (ii) fácil de usar e (iii) capaz de suportar diferentes níveis de abstracção, mantendo a coerência entre esses níveis. 2. PROTOTIPAGEM DE INTERFACES A prototipagem rápida de sistemas interactivos é utilizada com o objectivo de validar/avaliar ideias de desenho numa fase inicial do processo de desenvolvimento. Tentase, portanto, promover a colaboração entre todas as pessoas envolvidas no projecto (desde os gestores, designers e programadores até aos utilizadores finais), assim como facilitar os ciclos iterativos de revisão e teste. Nesta secção, descreve-se alguns métodos para o desenvolvimento rápido de protótipos de IU e a notação Abstracta Canónica: uma nova linguagem de especificação de protótipos abstractos que assenta numa

2 notação prática para definir e comparar ideias de interacção visuais [Constantine03]. 2.1 Técnicas para prototipagem rápida de Interfaces A linguagem de modelação UML tornou-se uma alternativa muito popular para a estruturação dos elementos de apresentação de sistemas interactivos [Nunes01]. Em particular, a notação Wisdom segue a norma do UML, o que promove e facilita a comunicação com os programadores e designers de software. Esta é uma boa estratégia para se conseguir alcançar uma maior taxa de aceitação das ferramentas de modelação. Outra estratégia, utilizada pela abordagem DiaMODL, combina este aspecto com uma ligação mais forte ao elementos concretos da IU [Trætteberg03], esperando-se com isso favorecer o processo de teste, uma vez que o utilizador lida com um écran concreto. A prototipagem de interfaces através de ferramentas de esboço electrónicas também obteve algum sucesso em sistemas como o SILK [Landay01] ou o DENIM [Newman03]. O esboço é importante durante o processo de prototipagem inicial porque incentiva a criatividade do designer: a ambiguidade inerente à dimensão ou tipo dos esboços encoraja a exploração de novos desenhos sem que o designer se perca em detalhes. Isto obriga a que o designer se concentre nos assuntos mais importantes desta etapa, como a estrutura geral e o fluxo da interacção [Landay01]. Contudo, a tarefa de reconhecimento dos componentes concretos a partir do esboço não é fácil [Landay01], uma vez que qualquer algoritmo de reconhecimento de padrões é susceptível de errar. Testes de usabilidade a estas ferramentas revelaram que alguns utilizadores sentiram dificuldades em manipular e introduzir elementos textuais, assim como em compreender a forma de seleccionar, agrupar e mover objectos [Landay01]. Em [Caetano02], apresenta-se uma abordagem visual à disposição de componentes concretos, estáticos da IU também baseada em reconhecimento de esboços. Estudos de usabilidade compararam a abordagem com um sistema comercial baseado num Interface Builder para concluir que a abordagem era mais bem sucedida [Caetano02]. 2.2 A notação Abstracta Canónica Protótipos Abstractos Canónicos (PAC) constituem uma nova linguagem de especificação de IU, proposta por Constantine [Constantine03]. Esta linguagem é composta por uma colecção estável de componentes de interface abstractos, desenvolvida a partir de muitas iterações em projectos da vida real. Estes componentes podem ser seleccionados a partir de uma palette a fim de construir protótipos abstractos canónicos. A existência de um conjunto normalizado de componentes abstractos facilita a comparação de alternativas de desenho, promovendo simultaneamente a comunicação entre os membros da equipa de desenvolvimento [Constantine03]. A notação simbólica inerente aos PAC é definida a partir de dois símbolos universais, genéricos e extensíveis: um material ou contentor genérico, representado por um quadrado e uma ferramenta ou acção genérica, representada por uma seta. Os materiais representam conteúdo, informação, dados ou quaisquer outros objectos da IU manipulados ou apresentados ao utilizador no decorrer de uma tarefa. As ferramentas representam operadores, mecanismos ou controladores que podem ser usados para manipular ou transformar os materiais. Através da combinação destas duas classes de componentes é possível gerar uma terceira classe de componentes genéricos, designados por híbridos ou materiais activos. Estes representam qualquer componente com características de ambos os componentes material e ferramenta, como por exemplo um campo para entrada de texto (um material manipulável que consistem num elemento de IU que apresenta informação que pode ser editada ou introduzida). A Figura 1 mostra os três símbolos básicos da notação Abstracta Canónica. A Figura contém a notação em mais detalhe. A notação completa e detalhada encontra-se em [Constantine03]. Figura 1: Os três símbolos básicos sobre os quais assenta a notação abstracta canónica (da esquerda para a direita): ferramenta abstracta genérica, material abstracto genérico e material activo (ou híbrido) genérico. Apesar de os PACs não possuírem um formalismo preciso nem a semântica necessária a fornecer ferramentas de suporte ou geração automática de IU, verificamos que a notação é suficientemente expressiva para gerar Interfaces concretas a partir da especificação abstracta canónica. Na secção 4 apresentamos a nossa ferramenta assim como uma prova de conceito onde são geradas interfaces HTML a partir de esboços de PACs. 3. PADRÕES DE INTERFACES Os padrões de desenho foram concebidos como um meio de capturar e reutilizar a experiência de desenho na arquitectura, como forma de ajudar os designers menos experientes. Os padrões são extracções e abstracções das lições aprendidas. Isto evita, em princípio, que o utilizador do padrão se confunda pelas circunstâncias ou por contexto irrelevante. O padrão ganha relevância e potencial ao abstrair a partir das várias experiências. O interesse crescente pelos padrões de IU gerou várias colecções concretas de padrões disponíveis ao público [Perzel99, Tidwell98]. Contudo, ainda não assistimos ao emergir de uma linguagem de padrões de IU consensual [Welie00]. 3.1 Conceitos e Definições Apesar de vários formatos terem sido definidos, um padrão de interface inclui normalmente 1) uma descrição de um problema e uma possível solução, 2) exemplos de utilizações de uma solução num design concreto, 3) razões que expliquem porque é que a solução realmente resolve o problema, 4) critérios que definem quando utilizar e quando evitar a solução e 5) relações com outros padrões de desenho [Trætteberg02]. Os diferentes formatos propostos seguem as ideias iniciais de Alexander. No contexto deste artigo, classificaremos os padrões de acordo com os seguintes atributos principais:

3 Identificação incluindo classificação e outros nomes claramente conhecidos para o mesmo padrão; Problema isto inclui aspectos como a intenção, motivação, aplicabilidade e problemas de usabilidade que são o alvo do padrão. Solução incluindo uma descrição dos elementos que compõem um padrão. A solução não deve descrever uma implementação particular uma vez que o padrão pode ser aplicado em inúmeras situações. Assim, o padrão deve descrever uma descrição abstracta de um problema de desenho e uma disposição geral de elementos que resolve esse problema. Em [Welie00], sugere-se que os padrões de IU devem focar-se nos aspectos de usabilidade que beneficiam, em primeira instância, os utilizadores finais. Esta posição é suportada pelo facto de muitas soluções no desenho de IU resolverem problemas que os designers têm mas que não beneficiam necessariamente os utilizadores, como por exemplo um banner numa página Web [Welie00]. 4. CANONSKETCH A ferramenta CanonSketch foi desenvolvida em primeiro lugar para suportar a edição e a criação de PACs. Existem vários tipos de ferramentas (por exemplo, aplicações de apresentação ou mesmo material concreto como quadros ou blocos de notas do tipo Post-It ) que podem ser usados para criar PACs. Contudo, para que se possa verificar e beneficiar de todas as vantagens desta notação, é necessário obter ferramentas de suporte em software [Constantine03]. Com o CanonSketch pretende-se fornecer uma ferramenta prática e de fácil utilização que suporte a notação Abstracta Canónica. A partir de uma notação fácil de aprender, desenvolvida a partir de muitas iterações em projectos da vida real, construiu-se uma ferramenta que fornece ao utilizador uma palette de componentes abstractos que podem ser desenhados, agrupados, etiquetados e modificados no interior de um espaço de desenho que representa um espaço de interacção. A ferramenta suporta todas as funcionalidades que se espera de um produto de software bem sucedido nos dias de hoje, como por exemplo alinhamento a uma grelha, múltiplos níveis para desfazer/re-fazer acções, etc. A ferramenta também suporta a criação (a nível sintáctico apenas) de modelos (espaços de interacção) Wisdom [Nunes00]. O Wisdom é um método baseado na linguagem UML, pelo que se espera aproveitar a experiência dos programadores desenhando uma extensão ao UML que suporte totalmente a notação canónica. A linguagem UML também é usada noutros trabalhos como [Koch01], relacionado com o desenvolvimento de aplicações hipermédia adaptativas, ou [Schwabe98] que descreve um método orientado a objectos para o mesmo domínio das aplicações hipermédia. No CanonSketch existem, assim, três vistas sincronizadas: a vista Wisdom, a vista Abstracta Canónica e uma vista de uma possível concretização da interface canónica, em HTML. Desta forma pretende-se obter uma ferramenta de modelação da interface que consiga suportar o pensamento do designer que passa por vários níveis de abstracção, alternando naturalmente entre cada nível, para trás e para a frente, à medida que realiza a especificação. A Figura 2 mostra o aspecto geral da ferramenta na vista canónica: no caminho para a construção de uma ferramenta fácil de aplicar à modelação de IU, seguimos uma abordagem substancialmente diferente da forma convencional como estas ferramentas são concebidas: em vez de foco ser dirigido aos formalismos e à semântica, começou-se com uma simples aplicação de desenho e acrescentou-se, de uma maneira incremental, os restantes mecanismos necessários à realização da interface. 4.1 Gerando automaticamente interfaces HTML Com o objectivo de verificar a riqueza expressiva da notação desenvolvida por Constantine e colegas, e também tendo em vista a geração automática de interfaces Figura 2: CanonSketch mostrando a vista canónica, intermédia entre a realização concreta (vista HTML) e especificação em Wisdom UML, a um mais alto nível.

4 Figura 3: Vista concreta: interface HTML gerada automaticamente a partir do modelo canónico da Figura 2. a partir dos modelos (mas sem possuir ainda um modelo semântico), realizou-se uma prova de conceito que pode ser exemplificada na Figura 3, onde se mostra uma interface em HTML gerada automaticamente pela ferramenta, a partir do PAC. Este protótipo de interface, sendo concretizado em HTML, é mostrado pela vista ao utilizador num browser embebido na ferramenta, sendo portanto navegável. Isto faz com que possa ser útil para testar junto do utilizador a estrutura da navegabilidade da interface especificada 1. Esta vista permite exemplificar, também, como se pode evoluir do protótipo abstracto da interface, para um protótipo concreto (e navegável) dessa mesma interface. O material genérico designado por Configuration Display é traduzido numa Tabela HTML com o mesmo nome. O contentor Standard Test List, que contém duas ferramentas abstractas ( Reset e Modify ) foi traduzido numa tabela que contém dois botões concretos HTML com o mesmo nome. A ferramenta Toggle designada pelo designer por Print na Figura 2 é traduzida numa Checkbox, como se vê na Figura 3. Esta tradução automática constitui, normalmente, um primeiro passo na passagem do abstracto para o concreto, pois normalmente após esta passagem o designer aplica a sua criatividade para obter uma interface concreta mais adequada. Além disso, num dado ambiente de implementação, cada componente canónico abstracto possui um número variável de concretizações. Na ausência de um modelo semântico incorporado no CanonSketch, esta prova de conceito mostra para já o potencial da notação canónica e cumpre o nosso objectivo de verificar a riqueza expressiva de um PAC. Também é parte da estratégia delineada: começar com uma ferramenta simples e fácil de usar, acrescentando incrementalmente os mecanismos semânticos em vez de construir uma ferramenta complexa e centrada nos formalismos subjacentes. 1 A ferramenta também é capaz de gerar um documento PDF dos modelos canónico/wisdom, que pode servir como um meio de documentar o processo e assumir decisões de desenho com o cliente. Na próxima secção delineamos uma especificação (inicial) para um modelo semântico comum que permita: (a) adicionar um formalismo e uma precisão à notação abstracta canónica, (b) um suporte UML a essa notação e (c) sincronização total entre vistas da especificação da interface a vários níveis de abstracção. 4.2 Um modelo semântico comum: um suporte UML para a notação canónica A notação Wisdom [Nunes01] consiste num conjunto de notações compatíveis com o UML, que suportam a modelação eficaz e eficiente de sistemas interactivos. Por isso, e para atingir o objectivo de construir e especificar uma extensão ao UML que suporte totalmente a notação canónica, pode-se estender e refinar a notação Wisdom. Além disso, a fim de manter vistas Wisdom/Canónicas totalmente sincronizadas, é necessário definir um modelo semântico comum. A especificação de um tal modelo conduzirá não apenas a que possa ser implementada uma ferramenta capaz de suportar o processo de desenho em várias etapas (desde as ideias de desenho iniciais até à implementação concreta) como também a uma complementaridade mútua entre as fraquezas e vantagens de cada modelo. O designer será capaz de escolher uma das vistas e alternar entre uma vista ou outra, variando o nível de abstracção utilizado, mas mantendo sempre a coerência entre os modelos. Para suportar a modelação dos aspectos de apresentação da IU, o método Wisdom propõe as seguintes extensões ao UML [Nunes01]: - <<Interaction Space>>, um estereótipo de classe que representa o espaço contido na IU onde o utilizador interage com todas as ferramentas e materiais no decorrer de uma tarefa ou conjunto de tarefas interrelacionadas; - <<navigate>>, um estereótipo de asociação entre dois espaços de interacção que denota uma mudança de espaço de interacção por parte do utilizador; - <<contains>>, um estereótipo de associação entre duas classes espaços de interacção que denota que a classe fonte (o contentor) contém a classe alvo (o contéudo); Este estereótipo de associação só pode ser utilizado entre dois espaços de interacção e é unidireccional;

5 - <<input element>>, um estereótipo de atributo que denota informação recebida pelo utilizador, isto é, informação sobre a qual o utilizador pode operar (notese a semelhança deste conceito com os híbridos da notação canónica); - <<output element>>, um estereótipo de atributo que denota informação apresentada ao utilizador, ou seja, informação que o utilizador recebe mas não manipula; - <<action>>, um estereótipo de operação que denota algo que o utilizador pode realizar na IU e que causa uma alteração significativa no estado interno do sistema. Foram identificados alguns problemas aquando da aplicação da abordagem Wisdom a padrões de IU que derivam de aspectos de apresentação capturados por alguns desses padrões, como por exemplo tamanho, posição ou utilização da cor [Nunes03]. A especificação de uma equivalência entre PACs e o modelo de apresentação Wisdom pode ajudar a resolver alguns destes problemas, adicionando também o formalismo necessário à notação canónica. Na Figura 4, apresentamos uma especificação inicial de uma equivalência entre PACs e o modelo de apresentação Wisdom. Comecemos pelo elemento base: um espaço de interacção Wisdom traduz-se inequivocamente num contexto de interacção [Constantine03] num PAC. A associação <<navigate>> pode ser unidireccional ou bidireccional; neste último caso, diz-se que há um retorno implícito na navegação. Isto tem essencialmente o mesmo significado que Constantine define ao descrever o mapa de navegação entre contextos de interacção [Constantine99]. Isto permite uma especificação parcial do comportamento dinâmico da interface (ao nível da navegação). O uso de diagramas de sequência UML também poderá permitir essa especificação. Um atributo estereotipado <<input element>> mapeia-se num material activo genérico, a menos que seja tipificado. Estes elementos de entrada, como vimos, especificam informação que o utilizador pode manipular a fim de realizar uma determinada tarefa. Um atributo estereotipado <<output element>> mapeia-se num elemento e uma operação estereotipada <<action>> mapeia-se numa ferramenta canónica abstracta. A associação estereotipada <<contains>> mapeia-se num contentor canónico, como mostra a Figura. A Figura 4 também apresenta uma primeira proposta de extensão ao modelo Wisdom para suportar PACs, concretamente através de dois atributos estereotipados: - <<input collection>>, um estereótipo de atributo que denota um conjunto de elementos de informação relacionados que são introduzidos ou manipulados pelo utilizador, isto é, um conjunto de <<input elements>>; uma <<input collection>> pode ser usada para seleccionar um ou mais valores de uma lista ou eleger um elemento numa tabela para uma determinada operação; - <<output collection>>, um estereótipo de atributo que denota um conjunto de elementos de informação relacionados e que são apresentados ao utilizador, isto é, um conjunto de <<output elements>>. Tipicamente, um <<output collection>> mostra informação acerca de um conjunto de elementos do mesmo tipo, por exemplo uma lista de resultados de pesquisa. Tipificando estes atributos pode-se mapear um modelo de apresentação Wisdom num conjunto de componentes Figura 4: Uma extensão ao modelo de apresentação Wisdom (esquerda) para suporte do modelo Canónico (direita).

6 abstractos canónicos que pertençam à classe dos Materiais e Híbridos. Por exemplo, um <<input collection>> tipificado como Choice pode ser mapeado numa colecção seleccionável (ver Figura 4). O designer começa assim por definir a estrutura geral da IU usando uma extensão UML, sendo essa especificação mapeada num ou mais contextos de interacção canónicos, onde o designer pode então expandir e detalhar o modelo em termos de posição, dimensão relativa e função interactiva. 4.3 Desenhando padrões de interface A capacidade de identificar padrões de IU e expressar a solução numa maneira abstracta e independente da implementação ou plataforma particular começa a tornarse cada vez mais importante, com o aumento do número de classes de dispositivos de informação. Possuir uma ferramenta que forneça um modelo semântico comum que ligue os componentes abstractos canónicos aos elementos Wisdom pode ajudar a resolver alguns dos problemas de expressão de padrões. Como veremos nesta secção, ambas as notações podem ser conjugadas em utilizadas simultaneamente para a especificação de padrões abstractos de interface. Apresentamos aqui alguns exemplos de aplicação da notação Wisdom a alguns padrões de IU (escolhidos de entre os disponíveis na colecção de padrões Amsterdam [Welie00]) assim como a representação canónica equivalente. Como refere Constantine, a capacidade de exprimir padrões de desenho em termos de modelos generalizados e abstractos tem tido pouca utilização nos padrões de IU. Num facto também apontado em [Nunes03], continua a ser necessária uma notação com aceitação por parte de toda a comunidade que consiga representar soluções frequentemente empregues em algumas tarefas de interacção de uma maneira abstracta que possa ser aplicada em inúmeros cenários de desenho. Nesta secção, apresentamos a aplicação das representações Wisdom UML e PAC a alguns padrões de interface, a fim de estudar as vantagens de uma notação em relação à outra, demonstrando assim que a complementaridade das vistas do CanonSketch pode ajudar a representar padrões a vários níveis de abstracção. Na Figura 5, apresentamos as representações Wisdom e Canónica para o padrão de IU identificado e classificado como Pré-visualização [Welie00]. Também apresentamos um exemplo concreto deste padrão (neste caso, um diálogo do Microsoft PowerPoint). O problema ocorre quando o utilizador procura por um item numa pequeno conjunto de itens e tenta encontrar o item desejado navegando nesse conjunto. Este padrão é particularmente útil quando a natureza do conteúdo do item não é a mesma que a natureza do seu índice de procura (por exemplo, um conjunto de imagens ou clips áudio indexadas pelo nome). A solução consiste em fornecer ao utilizador uma pré-visualização do item que estiver seleccionado num determinado instante [Welie00]. Como se pode verificar, a diferença não é muito crítica neste caso. A notação Wisdom, a um mais alto nível de abstracção, é mais compacta, em parte por ser baseada no UML. Mas a representação canónica apresenta a vantagem de especificar claramente que a lista de itens é colocada à esquerda da vista da pré-visualização, o que está em conformidade com o estilo de escrita ocidental, pelo que se ajusta à natureza da tarefa em causa: primeiro o utilizador selecciona um item, e só então tenta visualizálo, focando o olhar no material abstracto da prévisualização (à direita). Também se torna evidente que a representação canónica está muito mais próxima da representação concreta deste padrão, como se pode verificar comparando a representação canónica (em baixo, à direita) com a Figura 5: O padrão Pré-visualização : no topo um exemplo concreto (um diálogo do Microsoft PowerPoint). Em baixo: à esquerda a representação em Wisdom UML e à direita a representação canónica.

7 Figura 6: O padrão Disposição em grelha. Da esquerda para a direita, a representação usando UML (em Wisdom), a representação abstracta canónica e uma aplicação concreta (diálogo do Word 97) Figura 7: O padrão Wizard : À esquerda, a representação Wisdom, que permite expressar a navegação entre Wizard Steps. Ao centro a representação canónica e à direita uma concretização (Add Printer Wizard, Windows2000). concreta (no topo). No padrão seguinte, as vantagens da representação canónica são mais acentuadas. O padrão Disposição em grelha, igualmente obtido na colecção Amsterdam [Welie00], tenta resolver o problema de como compreender rapidamente a informação apresentada a fim de tomar uma acção que depende dessa informação [Welie00]. A solução recorrente consiste em dispôr todos os objectos numa grelha usando o menor número possível de linhas e colunas, tornando as células o maior possível. A Figura 6 mostra novamente um exemplo concreto: uma caixa de diálogo do MS Word 97. Usando este padrão, a disposição dos elementos no écran é mais consistente e o espaço é mais aproveitado, reduzindo o tempo de compreensão do utilizador. A Figura 6 mostra igualmente a representação canónica ao centro e a representação Wisdom à esquerda. Pensamos ser evidente o potencial da notação canónica para representar facilmente padrões de IU que lidem com aspectos espaciais ou com relações de disposição e posicionamento entre elementos de IU, de uma maneira abstracta. Além disso, ambas as notações possuem mecanismos embebidos que permitem a adição de comentários e anotações úteis à comunicação entre designers de interface. O elemento repetição, da notação canónica (representado por um >>> direccionado no sentido da zona de repetição) é expresso em Wisdom como uma associação <<contains>> de um para muitos, como mostra este exemplo (ver Figura 6). Para contrapor a esta diferença um padrão de IU onde a notação Wisdom é mais vantajosa, mostramos na Figura 7 a representação do padrão Wizard. Este padrão resolve o problema de um utilizador que pretende atingir um determinado objectivo mas necessita tomar algumas decisões antes de atingir por completo esse objectivo. A solução consiste em fazer navegar o utilizador pela tarefa inteira, um passo de cada vez. A Figura 7 mostra uma instanciação deste padrão que mostra como ele pode ser modelado em Wisdom UML (à esquerda) através de dois espaços de interacção: um para o corpo do Wizard e outro para cada passo do Wizard. Múltiplos passos são denotados pela cardinaldidade 1..* da associação <<contains>>. Acções abstractas (representadas como operações com o estereótipo <<action>>) são associadas a cada espaço de interacção para denotar as acções tipicamente representadas num padrão Wizard (e.g. next, back, cancel e finish). Este exemplo mostra a vantagem do Wisdom sobre PAC, nomeadamente no que diz respeito à modelação de relações de navegação entre os elementos abstractos da IU: não é possível, em PAC, modelar um contentor que permita navegar para outras instâncias dele mesmo (como o Wizard Step deste exemplo). A própria modelação da relação <<contains>> (um corpo de Wizard contém vários passos de interacção) é de difícil representação em PAC, a menos que se recorra a notações informais. Por fim, mostramos ainda um outro padrão de desenho abstracto: o padrão de Navegação em Contentores. Quando o utilizador necessita de encontrar um item numa colecção de contentores, a solução deste padrão consiste em dividir o espaço de interacção em três partes: uma para visualizar a colecção de todos os contentores, outra para visualizar um determinado contentor e outra para visualizar um determinado item desse contentor. A Figura 8 mostra um exemplo concreto deste padrão, no topo da Figura: o visualizador de Mail/News do Netscape Navigator. Uma vez mais, confronta-se também a representação canónica com a representação Wisdom.

8 Figura 8: O padrão Navegação em contentores (da esquerda para a direita): representação em Wisdom UML, representação canónica e aplicação concreta (leitor de Mail/News do Netscape). De forma a representar adequadamente este padrão de IU, é necessário ter em conta a dimensão e o posicionamento relativo. Esses aspectos suportam a tarefa do utilizador (e fazem parte da solução dada pelo padrão) uma vez que o utilizador selecciona, em primeiro lugar, um determinado contentor, depois um item contido nesse contentor e só então visualiza o item seleccionado. Seguindo a forma ocidental de leitura/escrita, o padrão coloca a colecção de contentores a ocupar a parte esquerda do espaço de ecrã, o contentor seleccionado a ocupar o topo direito e finalmente o item propriamente dito, na parte inferior direita. Este tipo de informação só pode ser capturado através da notação canónica. Em conclusão, observa-se que a notação Wisdom tem as suas vantagens sobre a canónica, sobretudo devido ao facto de ser compacta e ser baseada numa linguagem (UML) com grande aceitação e familiaridade por parte da maioria dos designers e programadores. Para a representação de padrões de navegação que envolvam muitos espaços de interacção, tal como o padrão Wizard [Nunes03] da Figura 7, o uso da notação Wisdom é mais vantajoso, expressivo e natural. Para padrões que lidem com aspectos espaciais e de tamanho, é preferível o PAC. A mente do designer de software trabalha a múltiplos níveis de abstracção, e daí a necessidade de existência de linguagens que suportem esses níveis mas que consigam, simultaneamente, manter a curva de aprendizagem baixa. Além disso são precisas ferramentas de suporte a esses múltiplos níveis de abstracção. Durante a compilação, estudo e especificação dos padrões de desenho abstractos apresentados nesta secção, verificou-se que o CanonSketch se assumiu como uma ferramenta capaz de comparar facilmente várias ideias de desenho, que podem ser expressas a vários níveis de abstracção. A compilação e manutenção de uma colecção de padrões (e sua comparação e comunicação) é também naturalmente simplificada. 5. CONCLUSÕES E TRABALHO FUTURO O uso de métodos formais para desenho de IU e linguagens de especificação de IU tem sido alvo de muita pesquisa na última década. A necessidade de integração entre as linguagens de modelação (nos seus vários níveis de abstração) é de uma importância reconhecida. Na sequência desse reconhecimento, apresentamos neste artigo uma extensão ao UML capaz de suportar uma notação mais informal (a notação canónica) que preenche a lacuna existente entre as ideias de desenho iniciais, de alto nível, e a concretização da interface. Além disso, exploramos o impacto e a utilidade que uma ferramenta que suporta a criação destes modelos assume na especificação e compilação de padrões de IU. Mesmo na ausência de um completo modelo semântico, uma ferramenta como o CanonSketch tem um valor significativo na especificação de sistemas interactivos complexos. O facto de ser possível gerar interfaces HTML a partir do modelo canónico mostra que a notação é suficientemente expressiva para no futuro ser possível suportar de uma forma precisa e completa técnicas de geração automática. Em relação a sistemas como o SILK, descrito na secção 2.1, o CanonSketch tem a vantagem de encorajar a exploração através do esboço sem a frustração que advém de um incorrecto reconhecimento de widgets. Também segue a filosofia do DiaMODL [Trætteberg03] (ligar o modelo aos elementos concretos), como o demonstra a alternância de vistas Wisdom/Canonical e HTML concreto. Como trabalho futuro, esperamos incorporar na ferramenta um modelo semântico preciso, que suporte as duas notações (ou outras), refinar o modelo de apresentação do Wisdom tirando partido das novas possibilidades oferecidas pela versão 2.0 do UML, e acrescentar outras funcionalidades à ferramenta. Também será interessante estudar a capacidade destes modelos na especificação de interfaces noutros contextos e/ou estilos de interacção (caso dos dispositivos móveis de informação), assim como formas de integração com o desenvolvimento de aplicações, a fim de diminuir o fosso existente entre indústria e academia. Conceptualmente, o CanonSketch e as linguagens de especificação de IU que esta ferramenta suporta não são limitadas a interfaces Web em HTML. Tanto o PAC como Wisdom UML são linguagens independentes de uma particular plataforma ou realização. Por este motivo será possível usar a ferramenta para especificar interfaces para PDA s, telemóveis e outros dispositivos. 6. REFERÊNCIAS [Alexander77] Alexander, C., S. Ishikawa, and M. Silverstein. A pattern language : towns, buildings, construction. 1977, New York: Oxford University Press. xliv, [Caetano02] Caetano, A., Goulart, N., Fonseca, M. and Jorge, J.: JavaSketchIt: Issues in Sketching the Look of User Interfaces. In Proceedings of the 2002 AAAI

9 Spring Symposium - Sketch Understanding, pages 9-14, Palo Alto, USA, [Constantine99] Constantine, L. and Lockwood, L. A. D.: Software for use : a practical guide to the models and methods of usage-centered design, Addison Wesley, Reading, Mass, [Constantine03] Constantine, L.: Canonical Abstract Prototypes for abstract visual and interaction design. In: Jorge, J., Nunes, N. and Falcão e Cunha, J. (eds.): Proceedings of DSV-IS 2003, 10th International Conference on Design, Specification and Verification of Interactive Systems. Lecture Notes in Computer Science, Vol Springer-Verlag, Berlin Heidelberg New York, [Gamma95] Gamma, E., et al., Design Patterns: Elements of Reusable Object-Oriented Software. Professional Computing Series. 1995, Reading Mass.: Addison-Wesley Longman. [Koch01] Koch, N. and Wirsing, M.: Software Engineeering for Adaptive Hypermedia Systems. In Paul de Bra, editor, Third Workshop on Adaptive Hypertext and Hypermedia, 8th International Conference on User Modelling, July [Landay01] Landay, J. and Myers, B.: Sketching Interfaces: Toward More Human Interface Design. IEEE Computer, pages 56-64, March [Myers00] Myers, B., Hudson, S. and Pausch, R.: Past, Present and Future of User Interface Software Tools. ACM Transactions on Computer Human Interaction, 7(1):3-28, March [Newman03] Newman, M., Lin, J., Hong, J. I. and Landay, J. A.: DENIM: An Informal Web Site Design Tool Inspired by Observations of Practice. Human-Computer Interaction, 18(3): , [Nunes00] Nunes, N. J.: Wisdom - A UML based architecture for interactive systems. In Proceedings of the DSV-IS 2000, Limerick, Ireland. Springer-Verlag. [Nunes01] Nunes, N. J.: Object Modeling for User- Centered Development and User Interface Design: the Wisdom Approach. PhD Thesis, University of Madeira, Funchal, Portugal, April [Nunes03] Nunes, N. J.: Representing User-Interface Patterns in UML. In Proceedings of OOIS'03-9th European Conference on Object-Oriented Information Systems, pages , Geneva, Switzerland, [Nunes04] Nunes, N. J. and Campos, P.: Towards Usable Analysis, Design and Modeling Tools. In Proceedings of the IUI/CADUI'04 Workshop on Making model-based UI design practical: usable and open methods and tools, Funchal, Portugal, January [Paternò00] Paternò, F., Model Based Design and Evaluation of Interactive Applications. Applied Computing, ed. R.J. Paul, P.J. Thomas, and J. Kuljis. 2000, London: Springer-Verlag. [Perzel99] Perzel, K. and D. Kane. Usability Patterns for Applications on the World Wide Web. in PLoP' [Schwabe98] Schwabe, D. and Rossi, G.: An Object- Oriented Approach to Web-Based Application Design, Theory and Practice of Object Systems 4(4), Wiley & Sons, New York. [Tidwell98] Tidwell, J., Common Ground: A Pattern Language for Human-Computer Interface Report. 1998, MIT. [Trætteberg02] Trætteberg, H.: Using User Interface Models in Design. In Proceedings of CADUI 02, [Trætteberg03] Trætteberg, H. Dialog modelling with interactors and UML Statecharts - A hybrid approach. In Proceedings of DSV-IS'2003, 10th International Workshop on Design, Specification and Verification of Interactive Systems. Springer-Verlag, [Welie00] Welie, M.v. and H. Troedtteberg. Interaction Patterns in User Interface. In PLoP 2000, 2000.