Tese Americo Revisada

Uma abordagem para projeto de aplicaes com
interao multimodal na Web

AmericoTalaricoNeto
Orientadora: Profa. Dra. RenataPontindeMattosFortes
Tese apresentada ao Instituto de Cincias Matemticas e de
Computao - ICMC-USP, como parte dos requisitos para
obteno do ttulo de Doutor em Cincias - Cincias de
Computao e Matemtica Computacional. VERSO
REVISADA.
USP So Carlos
Maio de 2011
SERVIO DE PS-GRADUAO DO ICMC-USP
Data de Depsito:
Assinatura:________________________
"Embora ningum possa voltar atrs e fazer
um novo comeo, qualquer um pode
comear agora e fazer um novo fim"
Chico Xavier
i
Agradecimentos
A Deus.
Aos meus familiares, Alina, Clarissa, Rosa Maria, Rosa Aparecida e Wladimir pelo
apoio em todos os momentos.
A orientadora, professora Renata, pela amizade, ajuda e confiana.
Aos colegas do laboratrio Intermdia e da empresa Nuance Communications Inc
pelo incentivo e colaborao.
ii
Resumo
O principal objetivo do desenvolvimento de aplicaes multimodais
possibilitar uma maneira mais natural dos seres humanos se comunicarem com as
mquinas, por meio de interfaces mais eficientes, intuitivas, fceis de usar e, de certa
forma, mais inteligentes.
No entanto, a literatura da rea mostra que a reutilizao, tanto de
conhecimento como de cdigo fonte, ainda apresenta problemas, dados a
complexidade do cdigo em sistemas multimodais, a falta de mecanismos eficientes
de testes de usabilidade e a dificuldade em se gerenciar a captura, o armazenamento e
a recuperao de conhecimento de projeto.
Nesta tese argumenta-se que a utilizao de uma abordagem sistemtica,
centrada no usurio, apoiada por uma ferramenta computacional e com um modelo
bem definido que permita o desenvolvimento de interfaces multimodais com a
reutilizao de Design Rationale, aumenta e melhora os nveis de usabilidade,
promove a identificao e utilizao de padres de projeto e o reso de componentes.
Para demonstrar esta tese, apresenta-se neste texto a abordagem para o
desenvolvimento de interfaces multimodais Web, MMWA, e o seu ambiente de
autoria, o MMWA-ae, ambos compostos por atividades que auxiliam a equipe de
projeto durante as fases de projeto, desenvolvimento e avaliaes de usabilidade.
So discutidos tambm os resultados obtidos com a execuo de trs estudos
de caso, realizados no ambiente acadmico, nos quais se buscou determinar a
viabilidade da abordagem e os benefcios que podem ser alcanados com a
combinao de diferentes tcnicas, a saber: design rationale, padres de projeto,
modelagem de tarefas, componentes de software, princpios de usabilidade,
avaliaes heursticas, testes com usurios, regras de associao, entre outras.
Os resultados evidenciam que a abordagem e seu ambiente de autoria podem
proporcionar diferentes benefcios para organizaes que desenvolvem sistemas
multimodais, incluindo o aumento da usabilidade e consequentemente da qualidade
do produto, bem como a diminuio de custos e da complexidade do
desenvolvimento com a reutilizao de cdigo e de conhecimento capturado em
projetos anteriores.
Palavras-chave: Interfaces multimodais, usabilidade, projeto de interfaces, Design
Rationale, reso.
iii
Abstract
The main goal of developing multimodal applications is to enable a more
natural way of communication between human beings and machines through
interfaces that are more efficient, intuitive, easier to use and, in a certain way, more
intelligent.
However, the literature shows that the reuse of both knowledge and source
code still presents problems, given the complexity of the code in multimodal
systems, the lack of efficient mechanisms to test the usability and the difficulty in
managing the capture, the storage and the recovery of design knowledge.
In this thesis it is discussed that the use of a systematic approach, user-
centered, supported by a computer tool and with a well defined model that allows the
development of multimodal interfaces with the reuse of DR, increases and improves
the usability levels, promotes the identification and the use of design patterns and the
reuse of components.
To demonstrate this thesis, it is shown in this text an approach to develop
Web multimodal interfaces (MMWA) and its authoring environment (MMWA-ae),
both composed of activities that help the design team during the different project
phases: design, development and usability evaluation.
We also discuss in this thesis the results obtained with the execution of three
case studies, executed in the academic environment, which aimed to determine the
feasibility of the approach and the benefits that can be achieved with the combination
of different techniques, such as: design rationale, design patterns, tasks model,
software components, usability principles, heuristic evaluations, user testing,
association rules, among others.
The results show clearly that the approach and its author environment can
provide different benefits to organizations that develop multimodal systems,
including the usability improvement and, consequently, the quality of the product, as
well as the decrease of costs and complexity since it encompasses the development
with reused code and design knowledge captured in previous projects.
Keywords: Multimodal Interfaces, usability, interface design, Design Rationale,
reuse.
iv
Glossrio
Gramtica: um arquivo que contm todas as palavras, sentenas ou frases que o
sistema Reconhecedor de Voz deve entender. Uma gramtica retorna para a
aplicao um significado semntico em resposta a uma entrada do usurio.
Log: uma expresso utilizada para descrever o processo de registro de eventos
relevantes que ocorrem na execuo de um software.
Nomatch: tipo de erro que ocorre nas interfaces de voz, no qual a fala do usurio no
confere com os dados presentes na gramtica.
NoInput: tipo de erro que ocorre nas interfaces de voz, no qual o usurio no fala
nada em resposta a um prompt.
Prompt: define uma mensagem falada da interface de voz para o usurio, com o
objetivo de obter uma entrada de informao.
Widget: um termo genrico para referenciar um componente de interface grfica.
Wiki: uma palavra do idioma havaiano que significa rpido. Na computao
utilizada para referir-se a um sistema colaborativo na Web para a criao e edio de
hiperdocumentos.
v
Abreviaturasesiglas
AS - Anlise de Solues
AU - Avaliao de Usabilidade
API - Application Programming Interface
DOM - Document Object Model
DR Design Rationale
DTD - Document Type Definition
DTMF - Dual-Tone Multi-Frequency
EC - Estudo de caso
EMMA - Extensible MultiModal Annotation
GUI - Graphical User Interface
IBIS - Issue-Based Information System
IT - Identificao de Tarefas
ISO - International Organization for Standardization
IHC - Interao Humano-Computador
JSGF - Java Speech Grammar Format
JSP - Java Server Pages
HTML - HyperText Markup Language
LOC - Lines of Code ou Linhas de Cdigo
MVC - Modelo-Viso-Controlador
MMWA - MultiModal Web Approach
MMWA-ae - MultiModal Web Approach authoring environment
MMLOG - MultiModal Log Analysis
MMHE - Multimodal Heuristic Evaluation
MCI - Modelo Comportamental Inicial
RT - Representao de Tarefas
SAAS - Software As A Service
vi
SALT - Speech Application Language Tags
SAX - Simple API for XML
SDK - Software Development Kit
TTS - Text To Speech
UML - Unified Modeling Language
UsiXML - User Interface eXtensible Markup Language
VUI - Voice User Interface
VXML - Voice eXtensible Markup Language
W3C - World Wide Web Consortium.
WIMP - Window, Icon, Menu, Pointing
X+V - eXtensible HyperText Markup Language + Voice
XHTML - eXtensible HyperText Markup Language
vii
ndicedeQuadros
Quadro 1 - Definio de usabilidade em diferentes fontes &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (*
Quadro 2 - Principais elementos da linguagem VXML organizados por escopo &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& *)
Quadro 3 - Sincronizao das interfaces de voz e grfica do segundo estudo de caso&&&&&&&&&&&&&&&&&&&&&&&&& ,-
Quadro 4 - Trecho do documento de projeto do segundo estudo de caso&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& -'
Quadro 5 - Trecho do formulrio de avaliao heurstica&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& .'
Quadro 6 - Exemplo de utilizao de DR em um estudo de caso com a MMWA&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ./
Quadro 7 - Descrio geral dos estudos de caso&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ('0
Quadro 8 - Uso de design rationale no estudo de caso 1 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (()
Quadro 9 - Dados gerais das avaliaes de usabilidade nos Estudos de Caso executados com a
MMWA &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ((-
Quadro 10 - Sincronizao das interfaces do sistema de localizao de rotas do EC2.&&&&&&&&&&&&&&&&&&&&&& ()*
Quadro 11 - Dados gerais dos Estudos de Caso executados com a MMWA&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (*)
Quadro 12 - Utilizao de comandos universais nos estudos de caso &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (+(
Quadro 13 - Trecho do MMLOG que apresenta mudana de modalidade aps um erro &&&&&&&&&&&&&&&&&&& (+)
Quadro 14 Exemplos de Regras da BASE-1 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (++
Quadro 15 - Regras da BASE-2&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (++
Quadro 16 - Exemplo de erro que pode ser corrigido com o uso das propriedades CARE&&&&&&&&&&&&&&&& (+-
Quadro 17 - Tempo de desenvolvimento das interfaces geradas no EC1 e EC3&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (,)
viii
ndicedeFiguras
Figura 1 - Usurio interagindo com o sistema Put That There (BOLT, 1980) &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& )
Figura 2 - Mapa de Leitura da Tese &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ('
Figura 3 - Modelo em camadas para usabilidade, traduzido de (VEER; WELIE, 2000). &&&&&&&&&&&&&&&&&&&& (/
Figura 4 - Padro de IHC Home Link (WELIE, 2010) &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ))
Figura 5 - Arquitetura para o desenvolvimento de aplicaes X+V. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& *-
Figura 6 - Exemplo de cdigo em X+V. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& *.
Figura 7 - Exemplo de cdigo de gramtica JSGF &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& */
Figura 8 - Componentes bsicos do Framework para Interao Multimodal do W3C (LARSON, 2003)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ++
Figura 9 - As atividades da MMWA: 1-Modelo Comportamental Inicial (MCI); 2-Identificao de
Tarefas (IT); 3- Representao de Tarefas (RT); 4- Anlise das Solues (AS); 5-Avaliao de
Usabilidade (AU). &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& +/
Figura 10 MMWA: Modelo Comportamental Inicial &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,(
Figura 11 - MMWA: Identificao de Tarefas &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,*
Figura 12 - Diagrama de transio de estados utilizado no estudo de caso 2 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,+
Figura 13 - Diagrama de atividades utilizado no estudo de caso 2&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,+
Figura 14 - MMWA: Representao de Tarefas&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,,
Figura 15 - MMWA: Anlise de Solues&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,/
Figura 16 - Trecho do Documento de Projeto obtido com a MMWA&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ,0
Figura 17 - MMWA: Avaliao de Usabilidade&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& --
Figura 18 - MMHE: Formulrio de avaliao heurstica&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& -0
Figura 19 - Fluxo de interao do MMLOG&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& .(
Figura 20 - MMLOG: Diagrama de Classe &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& .)
Figura 21 - MMLOG: grfico que mostra o nmero e o tipo dos erros na interface de voz para uma
tarefa especfica &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& .+
Figura 22 - MMLOG: grfico que compara o uso de dois tipos de modalidade para uma tarefa&&&&&&&&& .,
Figura 23 - Relacionamentos do Modelo IBIS adaptado de (KUNZ; RITTEL, 1970)&&&&&&&&&&&&&&&&&&&&&&&&& ..
Figura 24 - Exemplo de DR capturado durante o preenchimento da checklist&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ./
Figura 25 - MMWA-ae: rea de Projeto&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& /)
Figura 26 - MMWA-ae: Arquitetura&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& /+
Figura 27 - Captura de DR usando o MMWA-ae e a DokuWiki&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0)
Figura 28 - Trecho de cdigo de interface de voz gerado pelo MMWA-ae &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0*
Figura 29 - Trecho de cdigo de interface grfica gerado pelo MMWA-ae&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0+
ix
Figura 30 - Trecho de cdigo de sincronizao gerado pelo MMWA-ae&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0+
Figura 31 - Trecho da funo que captura eventos de erro&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0+
Figura 32 - Tempo mdio de interao na tarefa ChooseService para GUI e VUI&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0,
Figura 33 - MMLOG: Criao do protocolo de testes &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0,
Figura 34 - Protocolo de testes em execuo&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0-
Figura 35 - Cenrio de uso criado pelo MMLOG&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0-
Figura 36 - Elementos do Modelo de Tarefas da MMWA e o DR recuperado &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 00
Figura 37 - Sugesto automtica de padro de projeto multimodal para corrigir um problema de
usabilidade &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 00
Figura 38 - Trecho do modelo que mostra dois erros na interface de voz e uma interao grfica
correta &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (''
Figura 39 - Propriedades CARE escolhidas na fase de projeto&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (')
Figura 40 - Propriedades CARE utilizadas nos Testes com Usurios &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (')
Figura 41 - Trecho do modelo que permite a identificao de um problema de usabilidade &&&&&&&&&&&&& ('*
Figura 42 - MMWA-ae sugerindo uma correo, fundamentado em um problema de usabilidade
identificado pelo MMHE&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ('*
Figura 43 - Linha do tempo das atividades realizadas no doutorado&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (('
Figura 44 - Disposio dos elementos grficos no sistema de localizao de rotas. &&&&&&&&&&&&&&&&&&&&&&&&&& ((0
Figura 45 - Diagrama das camadas da aplicao de localizao de rotas do EC2. &&&&&&&&&&&&&&&&&&&&&&&&&&&&& ((0
Figura 46 - Elementos X+V da aplicao de localizao de rotas do EC2. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ()(
Figura 47 - Mtodos JavaScript da aplicao de localizao de rotas do EC2. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ())
Figura 48 - Mtodos ActionScript da aplicao de localizao de rotas do EC2. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ()*
Figura 49 - Interface desenvolvida no EC1, sem o auxlio do MMWA-ae &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ()-
Figura 50 - Interface do EC3, projetada com o MMWA-ae, sendo executada em uma plataforma de
testes de aplicaes mveis.&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ().
Figura 51 - Sistema de apresentaes de palestras desenvolvido no EC3 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& ().
Figura 52 - Filtro de voz utilizado na interface grfica&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (**
Figura 53 - Entrada de datas e hora&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (*,
Figura 54 - Tipos de erro identificados na interface de voz&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (*.
Figura 55 - Subdiviso dos tipos de erros &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (*/
Figura 56 - Taxa de Recuperao de Erro&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (*0
Figura 57 - Taxa de Recuperao de Erros em relao ao total de interaes analisadas&&&&&&&&&&&&&&&&&&& (*0
Figura 58 - Estrutura para identificao de padres de projeto &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& (+/
Figura 59 - Linha do tempo das atividades realizadas no doutorado e publicaes &&&&&&&&&&&&&&&&&&&&&&&&&&& (,.
x
ndice
Captulo 1. Introduo ......................................................................................................................... 1
1.1 Interao multimodal ............................................................................................................. 1
1.2 Motivaes para a pesquisa com interao multimodal ........................................................ 4
1.3 A tese..................................................................................................................................... 7
1.3.1 Objetivos desta tese........................................................................................................... 7
1.3.2 Escopo............................................................................................................................... 8
1.4 Organizao do texto............................................................................................................. 9
Captulo 2. A usabilidade no projeto de interfaces multimodais centrado no usurio....................... 11
2.1 Consideraes iniciais ......................................................................................................... 11
2.2 Definies de usabilidade e acessibilidade.......................................................................... 12
2.3 A usabilidade em sistemas multimodais.............................................................................. 15
2.4 Um modelo em camadas para obteno de requisitos considerando usabilidade................ 17
2.5 Princpios e guidelines para o projeto de interfaces multimodais Web............................... 18
2.6 Padres de Projeto para interfaces multimodais.................................................................. 20
2.7 Avaliao de usabilidade em interfaces multimodais.......................................................... 22
2.8 Consideraes finais............................................................................................................ 27
Captulo 3. Projeto de Interfaces Multimodais .................................................................................. 29
3.2 O uso de interao por voz em sistemas multimodais......................................................... 30
3.3 Tecnologias para o desenvolvimento de interfaces multimodais para a Web ..................... 31
3.3.1 VoiceXML ...................................................................................................................... 32
3.3.2 SALT............................................................................................................................... 33
3.3.3 XFORMSMM................................................................................................................. 34
3.3.4 EMMA............................................................................................................................ 34
3.3.5 XHTML+VoiceXML (X+V) .......................................................................................... 35
3.3.6 JSGF................................................................................................................................ 37
3.4 Abordagens para o projeto da interao multimodal ........................................................... 38
3.4.1 Estado da arte das abordagens para projeto de interfaces multimodais .......................... 39
3.4.2 Frameworks conceituais para desenvolvimento de sistemas multimodais Web............. 42
3.4.2.1 Framework ICARE (Interao, Complementaridade, Associao, Redundncia e
Equivalncia). ........................................................................................................................... 42
3.4.2.2 Framework para interao multimodal do W3C.................................................... 44
Captulo 4. Abordagem para o Desenvolvimento de Interfaces Multimodais Web (MMWA) ......... 47
xi
4.2 Definio da MMWA.......................................................................................................... 47
4.3 Modelo Comportamental Inicial (MCI)............................................................................... 50
4.4 Identificao das Tarefas (IT).............................................................................................. 53
4.5 Representao de Tarefas (RT) ........................................................................................... 54
4.6 Anlise das Solues (AS) .................................................................................................. 57
4.6.1 Sincronizao entre modalidades diferentes ................................................................... 60
4.6.2 Ativao de tarefas e estratgia de dilogo ..................................................................... 61
4.6.3 Estratgias de gerenciamento do dilogo........................................................................ 62
4.6.4 Estratgia de preveno e correo de erros ................................................................... 62
4.6.5 Estratgia de comandos Universais................................................................................. 64
4.6.6 Mecanismo de confirmao global/por tarefa................................................................. 64
4.7 Avaliao de Usabilidade (AU)........................................................................................... 65
4.7.1 Mecanismo de avaliao heurstica em interaes multimodais Web (MMHE) ............ 66
4.7.2 Mecanismo de gerao e anlise automtica de log em interaes multimodais Web
(MMLOG)..................................................................................................................................... 70
4.8 A utilizao de design rationale.......................................................................................... 75
4.9 Uma comparao com as abordagens pesquisadas.............................................................. 79
Captulo 5. Ambiente de autoria para o projeto de interfaces multimodais Web (MMWA-ae) ........ 81
5.2 Arquitetura de implementao do ambiente de autoria ....................................................... 81
5.3 Arquitetura de integrao das interfaces, mdulos e base de dados.................................... 84
5.3.1 Mdulo de Gerenciamento de Projetos ........................................................................... 85
5.3.2 Mdulo Gerenciador de Anlise de Tarefas.................................................................... 85
5.3.3 Mdulo Gerenciador de Modalidades ............................................................................. 86
5.3.4 Mdulo Gerenciador de Dilogo..................................................................................... 91
5.3.5 Mdulo de Gerenciamento de Avaliao de Usabilidade ............................................... 93
5.4 Desenvolvimento de interfaces multimodais orientado a modelos com o MMWA-ae....... 96
5.5 Vantagens da ferramenta ................................................................................................... 104
5.6 Limitaes da ferramenta .................................................................................................. 104
5.7 Consideraes finais.......................................................................................................... 105
Captulo 6. Estudos de caso ............................................................................................................. 107
6.1 Consideraes iniciais ....................................................................................................... 107
6.2 Metodologia....................................................................................................................... 107
6.3 Viso geral dos estudos de caso ........................................................................................ 109
xii
6.4 Estudo de caso 1 ................................................................................................................ 110
6.4.1 Definio do estudo de caso.......................................................................................... 111
6.4.2 Planejamento do estudo de caso.................................................................................... 111
6.4.3 Execuo do estudo de caso.......................................................................................... 113
6.5 Estudo de Caso 2 ............................................................................................................... 114
6.6 Estudo de Caso 3 ............................................................................................................... 124
6.7 Consideraes finais sobre os estudos de caso.................................................................. 128
Captulo 7. Anlise dos Resultados dos Estudos de Caso................................................................ 131
7.2 Usabilidade das interfaces geradas pelo MMWA-ae......................................................... 131
7.3 Estratgia de recuperao de erros .................................................................................... 135
7.4 Estratgia de comandos universais .................................................................................... 140
7.5 Estratgia de confirmao de entradas incertas ................................................................. 141
7.6 Regras de associao para a identificao de padres de interao .................................. 142
7.7 Identificao das propriedades CARE nos logs gerados pela tcnica MMLOG. .............. 145
7.8 Documentao e processo de captura, armazenamento e recuperao de DR .................. 146
7.9 Identificao de padres de projeto a partir de DR ........................................................... 147
7.10 Consideraes quanto reutilizao de cdigo................................................................. 149
7.11 Tempo gasto para projetar a interface e para obter o prottipo de interface para testes com
usurios. .......................................................................................................................................... 151
7.12 Consideraes finais.......................................................................................................... 152
Captulo 8. Concluses .................................................................................................................... 153
8.2 Contribuies..................................................................................................................... 154
8.3 Lies aprendidas .............................................................................................................. 155
8.4 Publicaes resultantes do trabalho realizado nesta tese................................................... 156
8.5 Limitaes e oportunidades para trabalhos futuros ........................................................... 159
Referncias Bibliogrficas .................................................................................................................. 161
Apndice A. Padres de projeto multimodal referenciados nesta Tese ......................................... 175
Apndice B. Relacionamentos entre heursticas, checklists, guidelines e princpios .................... 179
xiii
Apndice C. Exemplo de DR identificado em um estudo de caso ................................................ 185
Apndice D. Questionrio aplicado a um desenvolvedor que utilizou o MMWA-ae.................... 187
Apndice E. Trechos de artefatos desenvolvidos no EC1 ............................................................. 189
Captulo 1 - Introduo
1
Captulo 1. Introduo
Neste captulo so apresentadas as principais motivaes que nortearam esta pesquisa
sobre interfaces multimodais Web com o uso das modalidades grfica (GUI) e de voz (VUI),
bem como os significados e definies de termos que sero usados no contexto deste
trabalho. Tambm sero abordados os objetivos, as contribuies e o escopo da tese e, no
final, ser apresentado um resumo dos prximos captulos.
1.1 Interao multimodal
No mundo real as pessoas estabelecem entre si interaes multimodais, ou seja, elas
fazem uso de diversos modos de comunicao para executar suas tarefas cotidianas. Imagine
a seguinte situao, dois amigos esto conversando em uma festa. Enquanto um deles fala, o
outro est concentrado no assunto, mas no deixa de perceber tambm a linguagem corporal
de seu amigo, os gestos e a expresso facial que acompanham as suas palavras. Durante a
conversa, o interlocutor ir adaptar seu tom de voz ao ambiente em questo para que o
receptor possa no apenas ouvi-lo como tambm compreend-lo. Assim, caso haja msica,
ser preciso que os amigos falem mais alto. Eles podem tambm seguir o ritmo da msica,
falando mais rpido ou mais devagar, permitindo um melhor entendimento do que est sendo
dito e a continuidade do dilogo entre os dois amigos.
J a Interao Humano-Computador (IHC) no apresenta at o momento esse aspecto
multimodal, pois poucas das interfaces grficas desenvolvidas nos ltimos 20 anos permitem
que os usurios se comuniquem da mesma maneira que eles naturalmente se comunicam
quando esto se movimentando, usando as mos para realizar outras tarefas, olhando para
outro lugar ou interagindo com outra pessoa (KLEMMER et al., 2000). Uma razo para isso
o grande dispndio de recursos e tempo para desenvolver uma interface multimodal e o fato
dos processos ainda estarem se estabelecendo (FLIPPO; KREBS; MARSIC, 2003).
No entanto, nos ltimos anos, o progresso tecnolgico no projeto de novos
dispositivos e o crescimento cientfico no campo da Interao Humano-Computador tm
possibilitado novas formas de interao que esto migrando da pesquisa para produtos
comerciais. Desde o aparecimento do sistema Put That There de Bolt (1980), Figura 1, que
processa objetos grficos em uma tela com o uso de reconhecimento de voz e dispositivos de
apontamento em paralelo, uma diversidade de pesquisas no campo multimodal tornaram-se
conhecidas, incluindo: combinaes de modalidades, tais como voz, grfico e gestos
(JOHNSTON, 2009
LALANNE, 2009
adaptao de interfaces e dispositivos
acessibilidade e usabilidade
o IPad da Apple,
dos usurios e so sucessos de venda e crtica.
essencial para a prxima gerao de interfaces com a crescente proliferao de dispositivos
de interao, a crescente disponibilidade de servios na
devido ao grande poder expressivo, a naturalidade e a portabilidade que interfaces
multimodais oferecem aos usurios para executar suas tarefas dirias
LUNSFORD
grfico, eleva o nmero de problemas de usabilidade e questes de interao que os
projetistas
NSTON, 2009
LALANNE, 2009
acessibilidade e usabilidade
Figura 1 -
Dispositivos que permitem o uso de novas modalidades de interao como o IPhone
Pad da Apple, Inc
Portanto, o apoio a diversas modalidades de interao tornou
interao, a crescente disponibilidade de servios na
LUNSFORD; COULSTON, 2005
No entanto, a utilizao de modalidades combinadas, como a fala, o toque, gestos e
projetistas e desenvolvedores enfrentam, como requisitos de sincroniza
NSTON, 2009), estratgias de fuso e fisso de modalidades
LALANNE, 2009), o gerenciamento de dilogo
acessibilidade e usabilidade (
- Usurio interagindo com o sistema
Inc e o Wii
; COULSTON, 2005
e desenvolvedores enfrentam, como requisitos de sincroniza
, estratgias de fuso e fisso de modalidades
, o gerenciamento de dilogo
(HUBERT, 2006
Usurio interagindo com o sistema
da Nintendo
; COULSTON, 2005).
2
, o gerenciamento de dilogo
adaptao de interfaces e dispositivos (BERTI; PATERNO, 2005
BERT, 2006).
Usurio interagindo com o sistema
da Nintendo
, ganharam r
(MCGEE; COHEN; OVIATT, 1998
BERTI; PATERNO, 2005
Usurio interagindo com o sistema Put That There
, ganharam rapidamente a ateno e a preferncia
interao, a crescente disponibilidade de servios na Web
Captulo 1
, estratgias de fuso e fisso de modalidades (DUMAS; INGOLD;
MCGEE; COHEN; OVIATT, 1998
BERTI; PATERNO, 2005
Put That There (BOLT, 1980)
pidamente a ateno e a preferncia
Web para a populao mundial e,
e desenvolvedores enfrentam, como requisitos de sincronizao e integrao
DUMAS; INGOLD;
MCGEE; COHEN; OVIATT, 1998
BERTI; PATERNO, 2005) pesquisas em
(BOLT, 1980)
Portanto, o apoio a diversas modalidades de interao tornou-se um requisito
para a populao mundial e,
multimodais oferecem aos usurios para executar suas tarefas dirias (OVIATT;
o e integrao
Introduo
DUMAS; INGOLD;
MCGEE; COHEN; OVIATT, 1998),
pesquisas em
Dispositivos que permitem o uso de novas modalidades de interao como o IPhone e
se um requisito
para a populao mundial e,
OVIATT;
o e integrao, bem
3
como restries que devem ser consideradas nas fases de projeto (COHEN; GIANGOLA;
BALOGH, 2004). Negligenciar estes temas ao projetar interfaces multimodais pode acarretar
uma srie de problemas, porque os usurios acham difcil entender as novas interfaces e
tambm porque o desempenho das tarefas ser menos eficiente (BOLT, 1980).
Consequentemente, os projetistas esto expostos a um desafio cada vez maior: alm
de terem que aprender diferentes linguagens de programao e tecnologias acessveis e
aplic-las para obter o cdigo da aplicao multimodal, eles precisam entender quais so as
melhores prticas neste campo de pesquisa e como testar as interfaces projetadas com
usurios reais, com diferentes comportamentos, de uma forma eficiente antes do lanamento
do produto.
Alm disso, a equipe do projeto deve se preocupar em como promover a reutilizao
do cdigo de aplicao e do design rationale (DR), ou seja, os porqus das decises e as
lies aprendidas a fim de obter um bom equilbrio entre o custo e o esforo de
implementao de interfaces multimodais.
Nesta tese de doutorado, consideram-se as particularidades da interao multimodal e
concentra-se em resolver os principais problemas mencionados na literatura, expostos nos
pargrafos anteriores, com o uso da MultiModal Web Approach (MMWA), que se
fundamenta na experincia terica e emprica adquirida pelos projetistas durante o processo
de projeto da interao multimodal.
Essa experincia documentada na forma de DR, princpios e padres de projeto que
podem ser compartilhados e aplicados, no s pela equipe de projeto de uma nica aplicao
multimodal, durante vrias iteraes para refinar esse mesmo sistema, mas tambm por
projetistas de diferentes aplicaes.
Alm disso, fundamentado na experincia adquirida na aplicao da MMWA em
projetos reais (NETO; FORTES, 2009), e com base nas observaes do fluxo de trabalho da
MMWA, foi desenvolvida uma ferramenta de autoria que orienta os projetistas,
desenvolvedores e testadores de usabilidade, ou seja, a equipe do projeto, atravs das etapas e
atividades da MMWA.
A vantagem dessa ferramenta de autoria, chamada MMWA-ae, que ela sugere
alternativas de projeto com base na coleta prvia de DR (NETO et al., 2009) e dos
conhecidos padres de projeto (GAMMA et al., 1995) e padres de interao (BORCHERS,
2001; RATZKA; WOLFF, 2006). Esses padres foram estendidos para apoiar a teoria
multimodal.
4
O MMWA-ae tambm implementa os princpios e checklists (listas de verificao)
identificados neste trabalho para que os projetistas possam utilizar as solues bem sucedidas
para problemas recorrentes nesse contexto, juntamente com seu DR.
Embora a abordagem tenha sido originalmente concebida para o domnio da Web,
acredita-se que ela possa ser til para a concepo e avaliao das aplicaes com interao
multimodal em outros contextos, como dispositivos mveis, por exemplo.
1.2 Motivaes para a pesquisa com interao multimodal
A Interao Humano-Computador Multimodal permite ao usurio utilizar vrios
modos de comunicao para interagir com um sistema, tais como voz, toque, gestos e
movimentos.
Os modos podem ser utilizados simultaneamente ou em seqncia e em combinao
ou independentemente, alm da tradicional entrada via teclado e mouse, e sada atravs de
uma interface grfica. A relao entre um dispositivo de entrada ou sada (microfone, teclado,
tela sensvel ao toque) e uma linguagem de interao (linguagem natural, manipulao direta)
chamada modalidade. Consequentemente, a interao multimodal pode ser definida
tambm como a utilizao de duas ou mais modalidades para interagir com um sistema.
O advento dos sistemas multimodais representa uma mudana de pesquisas com o
paradigma das interfaces convencionais do tipo Janelas, cones, Menus, Ponteiros (WIMP em
ingls) para pesquisas com um novo paradigma que tem como objetivo fornecer aos usurios:
maior poder de expresso, naturalidade, flexibilidade e portabilidade (SCHAPIRA;
SHARMA, 2001). Sistemas WIMP so determinsticos, uma vez que eles se concentram
sobre a posio do cursor em uma tela, j os sistemas multimodais so probabilsticos, uma
vez que utilizam identificadores de modalidades que trabalham com a incerteza (DUMAS;
INGOLD; LALANNE, 2009).
As pesquisas atuais sobre a interao multimodal so constantemente
interdisciplinares, incluindo tpicos que vo da Engenharia de Software Psicologia. Alm
disso, h um desejo de estender a Web para permitir aos usurios selecionar dinamicamente o
modo mais adequado de interao para as suas necessidades momentneas, atravs do
desenvolvimento de interfaces mais eficientes, que possam ser ativadas de acordo com o
modo escolhido pelos usurios (OVIATT, 1999b).
5
Estudos mostram que as tarefas novas e complexas so executadas de forma mais
rpida com o uso de mltiplas modalidades de interao (COHEN; MCGEE; CLOW, 2000;
RATZKA, 2008)
Como descrito em Narayan et. al. (2004), o uso de mltiplos modos de interao
aumenta a quantidade de informao em um dilogo, melhora o conhecimento mtuo entre o
sistema e o usurio, reduz a ambigidade e simplifica o dilogo. A idia para um projeto que
respeite e considere as diferenas de forma indiscriminada que os objetivos estabelecidos na
interao com um sistema computacional sejam alcanados com eficcia, eficincia e
satisfao por um amplo conjunto de usurios.
A interao multimodal oferece benefcios em termos de facilidade de uso e pode
aumentar a usabilidade das interfaces, pois um ponto fraco de uma modalidade pode ser
superado com o uso de um ponto forte de outra modalidade (OVIATT, 1999a). Alm disso,
permite a compensao mtua de erros de reconhecimento das tecnologias probabilsticas
(OVIATT, SHARON, 2003). H muitas vantagens no uso das interfaces multimodais,
incluindo:
" Aumento na facilidade de uso dos dispositivos pequenos e complexos permitindo
uma interao mais natural na execuo das tarefas. As interfaces multimodais
podem oferecer aos usurios a habilidade de usar o modo de interao que melhor
se adapta a uma situao particular, aumentar a taxa de tarefas que o usurio
consegue completar, reduzir o tempo e o esforo do usurio para completar uma
tarefa, proporcionar maior satisfao do usurio atravs da preveno e
recuperao rpida de erros de maneira mais intuitiva (OVIATT et al., 2000).
" Flexibilidade, pois os sistemas multimodais permitem aos usurios selecionar e
alternar entre os modos de entrada evitando sobrecarga fsica ou mental na
utilizao de uma modalidade.
" A interface pode acomodar uma ampla gama de usurios, tarefas e ambientes,
inclusive os usurios temporariamente ou permanentemente impossibilitados, e
outros casos em que uma modalidade pode no ser suficiente ou adequada para
completar uma tarefa.
" Acessibilidade, quando mais de um tipo de interao est disponvel, os usurios
com dificuldades ou restries utilizao de um dispositivo podem faz-lo de
outra forma, garantindo o acesso informao (BOUILLON;
VANDERDONCKT; CHOW, 2004).
6
Por outro lado, projetar interfaces que se beneficiam dos avanos em tecnologias de
reconhecimento como o reconhecimento de voz e os dispositivos novos de interao ainda
uma atividade complexa, mas tm permitido novas possibilidades de pesquisa no campo de
interfaces multimodais (CHANG; BOURGUET, 2008).
Embora as vantagens das interfaces multimodais sejam evidentes, o desenvolvimento
de projetos multimodal ainda um desafio (OVIATT; COULSTON; LUNSFORD, 2004),
devido falta de ferramentas que apropriadamente orientam o projetista, no projeto,
implementao e avaliao das interfaces multimodais. Alm disso, h a necessidade de
processar entradas de grupos de usurios heterogneos e integrar vrias modalidades de
entrada de sada que podem operar em paralelo ou simultaneamente e de lidar com erros de
reconhecimento e de sincronizao para a gerao de interfaces multimodais eficientes.
A falta de entendimento sobre a melhor forma de combinar os diferentes modos de
interao nas interfaces muitas vezes leva a projetos de interface com pouca usabilidade
(CHANG; BOURGUET, 2008).
Os princpios e tcnicas de usabilidade utilizados para as interfaces grficas
tradicionais (GUI) no se aplicam necessariamente aos sistemas multimodais (OVIATT,
SHARON, 2003), para os quais alguns tpicos importantes como o projeto das entradas e
sadas de informaes, da adaptabilidade, da consistncia e do tratamento de erros, alm de
tpicos como dependncias culturais, comportamentais e de personalidade individual devem
ser considerados (REEVES et al., 2004).
Isto significa que o projeto bem sucedido da interao multimodal requer o apoio da
cincia cognitiva na coordenao da percepo humana e no desenvolvimento de interfaces
utilizando modalidades mais naturais.
Dessa forma, o contexto deste trabalho se orienta na investigao de um suporte
conceitual e ferramental necessrio para a confeco de um projeto de interao multimodal,
por meio de uma abordagem com etapas fundamentadas em um ferramental terico para
apoiar a gerao automtica de prottipo de interface multimodal nas modalidades grfica,
toque e voz para a Web, considerando-se para isso as questes relacionadas acessibilidade,
usabilidade e experincia do usurio. O diferencial deste trabalho est na:
" Utilizao de um mecanismo automtico para captura e recuperao de DR que
facilita a identificao de padres de projeto.
7
" Utilizao de avaliao de usabilidade por meio de interaes com usurios reais
que considera dados obtidos da interao desses usurios para a melhoria das
interfaces antes do projeto final ser entregue e colocado em uso.
Nos prximos captulos desta tese sero apresentados os mtodos, tcnicas e
frameworks para o projeto de interfaces multimodais Web e ser discutido que eles pouco
consideram tpicos relacionados, como usabilidade. Como soluo para este problema, ser
apresentada a abordagem proposta e os resultados obtidos utilizando-a em estudos de caso.
1.3 A tese
Nesta tese argumenta-se que o projeto, desenvolvimento e teste de usabilidade das
interfaces multimodais so atividades que se beneficiam da aplicao de uma abordagem
sistemtica, ou seja, uma metodologia composta por um modelo de tarefas bem definido, um
mtodo para manipular esse modelo e para promover a reutilizao de conhecimento e uma
ferramenta que implemente o mtodo definido e que efetivamente auxilie a equipe de projeto
a desenvolver interfaces multimodais Web.
Dados:
" Potencial do uso de vrias modalidades de interao para resolver problemas de
usabilidade e acessibilidade, promover o Design Universal e agilizar a execuo
de tarefas.
" Benefcios do uso de padres de projeto e DR no desenvolvimento.
" Necessidade de um processo completo e sistemtico para o projeto,
desenvolvimento e testes de interfaces multimodais centrado no usurio.
" Necessidade de um mecanismo para reutilizao de conhecimento e cdigo fonte.
" Necessidade de se realizar avaliaes de usabilidade em estgios iniciais do
desenvolvimento de software.
A tese sendo defendida a de que uma abordagem sistemtica, centrada no usurio,
apoiada por uma ferramenta computacional, com um modelo bem definido que permita o
desenvolvimento de interfaces multimodais com a reutilizao de DR aumenta e melhora os
nveis de usabilidade, promove a identificao e utilizao de padres de projeto e o reuso de
componentes.
1.3.1 Objetivos desta tese
Para validar esta tese foram definidos os objetivos a seguir que sero aprofundados
durante a leitura deste texto:
8
" Propor uma abordagem para o projeto de interfaces multimodais Web (MMWA).
" Identificar e implementar um mecanismo no intrusivo que proporcione a captura,
o armazenamento e a recuperao de DR, de forma que se obtenha uma base de
dados da qual ser possvel extrair padres de projeto.
" Prover um mecanismo ao projetista e ao desenvolvedor para facilitar a consulta de
DR e utilizar padres de projeto de forma que possa ocorrer gerao de cdigo
fonte fundamentado em componentes, promovendo reso e diminuindo o tempo
de projeto, desenvolvimento e testes.
" Validar o uso da abordagem proposta em estudos de caso (ECs) comparando com
mtodos existentes.
" Desenvolver um ambiente de autoria que permita a utilizao da abordagem
proposta em projetos multimodais Web.
1.3.2 Escopo
As modalidades pesquisadas nesta tese so:
" Grfica:
o Dispositivos: vdeo, teclado e mouse, Tablet PC (toque);
o Linguagem de Interao: manipulao direta.
" Voz:
o Dispositivos: Microfone e caixa de som ou headset;
o Linguagem de Interao: reconhecimento e sntese de voz.
A escolha por estas modalidades se deve ao fato do doutorando possuir vnculo
empregatcio com a empresa Nuance Communications Inc, empresa lder no ramo de
reconhecimento e sntese de voz, que apoiou este projeto e incentivou a pesquisa na rea
multimodal. Alm disso, estudos apontam que 80% dos usurios preferem uma mistura de
interfaces baseadas em comando e em dilogo ao invs de uma interface totalmente em
linguagem natural (NICHOLS et al., 2002).
Observa-se tambm que atualmente no possvel obter um desempenho perfeito na
interao utilizando-se somente reconhecimento de voz, pois as entradas de voz podem ser
corrompidas por barulho, o reconhecimento probabilstico e o significado pode ser
ambguo. As outras modalidades existentes no fizeram parte do escopo desta pesquisa.
A mesma motivao do trabalho na empresa Nuance Communications influenciou a
escolha do ambiente Web para o desenvolvimento da pesquisa, pois a empresa membro da
W3C e participa ativamente nos grupos de trabalho de linguagens que envolvem o uso de voz
9
e multimodalidade tais como VXML, X+V, EMMA (Extensible MultiModal Annotation)
(BAGGIA et al., 2007), entre outras.
A abordagem considera o desenvolvimento de interfaces multimodais convencionais,
portanto, esto fora do escopo a pesquisa por interfaces 3D, tangveis, imersivas; a pesquisa
de arquiteturas e notaes formais e a transformao ou adaptao de interfaces.
Alm disso, foi priorizada a definio de uma abordagem prtica sem a cobertura
extensa do ciclo de vida do software para que a sua utilizao e avaliao em projetos
acadmicos fossem realizadas com maior controle.
O pblico alvo desta tese a comunidade de pesquisa de IHC, os profissionais
envolvidos no projeto, implementao e testes de interfaces multimodais Web, alm de
estudantes em nvel de graduao e ps-graduao.
1.4 Organizao do texto
Esta tese est organizada em 8 captulos descritos a seguir e resumidos no mapa de
leitura da Figura 2.
No Captulo 2 so discutidos os conceitos de usabilidade para o projeto,
desenvolvimento e avaliao de interfaces multimodais. No Captulo 3 so apresentadas as
tecnologias, as abordagens e frameworks pesquisados na literatura com o objetivo de formar a
base para o desenvolvimento deste trabalho. Nesses dois captulos apresentado, portanto, o
Estado da Arte.
No Captulo 4 proposta a Abordagem para o Desenvolvimento de Interfaces
Multimodais Web (MMWA), uma ferramenta conceitual composta por atividades e tcnicas,
utilizada para o projeto de interfaces multimodais Web. No Captulo 5, so apresentadas as
arquiteturas de implementao e de integrao do ambiente de autoria desenvolvido para
facilitar o uso da MMWA em projetos multimodais Web, bem como as principais
caractersticas do modelo de tarefas desenvolvido neste contexto. Nesses dois captulos
descrito o trabalho que foi desenvolvido no perodo do doutorado.
No Captulo 6 apresentada a metodologia usada neste trabalho e uma descrio dos
estudos de caso executados e no Captulo 7 so apresentados e discutidos os resultados mais
significantes obtidos aplicando-se a metodologia proposta com as ferramentas criadas. Nesses
dois captulos apresentado o mecanismo de validao da ferramenta e da abordagem
proposta.
Por ltimo, no Captulo 8 so discutidas as concluses.
Figura Figura 2 - 2 - Mapa de Leitura da Tese
4WXYHSW HI 2EWS
?IWYPXEHSW
10 10
Mapa de Leitura da Tese
>VSNIXS HI 7RXIVJEGIW <YPXMQSHEMW
Captulo 1
Captulo 1 - Introduo Introduo
Captulo 2 - A usabilidade no projeto de interfaces multimodais centrado no usurio
11
Captulo 2. A usabilidade no projeto de
interfaces multimodais centrado no
usurio
2.1 Consideraes iniciais
No transcorrer desta dcada, inmeras pesquisas em diversas reas da computao
mostraram a preocupao em considerar o usurio como um importante participante no
processo de projeto de software com usabilidade (HOLZINGER, 2005; HUBERT, 2006;
NIELSEN, 2006; SEFFAH et al., 2006; KAMEL; AIT AMEUR, 2007; RAJANEN; IIVARI,
2007; BERNHAUPT, 2008; BERNHAUPT et al., 2008; CHANG; BOURGUET, 2008;
NETO; FORTES, 2009), pelo fato de que o software automatiza as tarefas cotidianas do
usurio e o usurio tem necessidades que devem ser atendidas pelo produto. Essas
necessidades so expressas por algumas palavras que so usadas como mtricas na avaliao
de usabilidade do software: aprendizagem, eficcia, eficincia, satisfao, intuitividade, entre
outras.
Portanto os mtodos de projeto centrados no usurio compartilham o raciocnio que os
sistemas devem ser desenvolvidos para as pessoas que iro utiliz-lo, considerando as suas
necessidades e o ambiente no qual as tarefas sero executadas, ou seja, so consideradas as
perspectivas humanas (ou contexto de uso fsico, representando todas as situaes que
influenciam o uso do sistema), da interao (ou contexto tecnolgico, considerando a
tecnologia disponvel ao usurio como rede e dispositivos de entrada e sada) e do trabalho
(ou contexto social, representando todas as situaes que influenciam o uso do sistema)
(WELIE; VAN DER VEER; ELINS, 1999).
Os sistemas e suas interfaces so desenvolvidos para os humanos, ento faz-se
necessrio entender as suas habilidades e limitaes, especialmente as habilidades cognitivas,
perceptivas, sensoriais e motoras, e a relao entre as mtricas de usabilidade e as
caractersticas dos seres humanos. Por exemplo, o conhecimento das pesquisas sobre a
memria de trabalho pode melhorar a facilidade de aprendizado dos sistemas, enquanto que o
conhecimento da memria de longa durao e suas relaes com o modelo mental do usurio
podem ajudar na correo de problemas de usabilidade que so causados pela inconsistncia
entre esse modelo mental e a estrutura das interfaces (OVIATT, S., 2003).
12
No tocante interao, necessrio entender o tipo de soluo que funciona para uma
determinada tarefa. Esse conhecimento do porque algumas interfaces funcionam melhor do
que outras pode ser obtido tanto da experincia prtica do projetista como do conhecimento
capturado nas tcnicas descritas neste captulo, como guidelines, princpios, design rationale,
padres de projeto, etc. Por isso faz-se necessrio pesquisar formas para capturar e estruturar
o raciocnio de projeto, bem como criar modos eficientes de busca e apresentao desse
raciocnio, incluindo a criao de uma linguagem comum de comunicao, para que novos
projetistas se capacitem mais rpida e eficientemente.
De igual importncia, a perspectiva do trabalho deve ser considerada durante o
projeto da interao, pois o humano interage com o sistema para desempenhar um trabalho,
ou uma srie de tarefas. Tpicos como a tecnologia disponvel e o contexto de uso devem ser
considerados.
Existem muitas definies sobre usabilidade e diversos autores criaram ao longo dos
anos diferentes tcnicas para ajudar na melhoria da usabilidade, tais como: guidelines,
padres, normas, heursticas e checklists. Mas necessrio esclarecer como certas escolhas
de projeto influenciam na usabilidade.
Para os projetistas e desenvolvedores de software difcil ou trabalhoso escolher qual
dessas tcnicas deve ser escolhida e quando deve ser utilizada. Portanto, necessrio estudar
essas diferentes tcnicas para que seja possvel identificar seus pontos fracos e fortes com o
objetivo de utilizar o que h de melhor no projeto de interfaces multimodais.
Nesse sentido, o objetivo com este captulo apresentar as definies de usabilidade e
acessibilidade (Sees 2.2 e 2.3), bem como discutir os principais tpicos de pesquisa para a
obteno de requisitos (Seo 2.4), projeto (Sees 2.5 e 2.6) e avaliao de usabilidade
(Seo 2.7) para interfaces multimodais. Essa discusso faz-se necessria para a proposta da
abordagem tema desta tese que ser apresentada no Captulo 4.
2.2 Definies de usabilidade e acessibilidade
Na literatura so encontradas diferentes definies para usabilidade, pois ela no pode
ser expressa em uma medida objetiva.
Usabilidade , na maioria das vezes, definida como a facilidade de uso e a
aceitabilidade de um sistema para uma classe particular de usurios executando tarefas
especficas em um ambiente especfico. A facilidade de uso afeta o desempenho e a
satisfao dos usurios, enquanto que a aceitabilidade afeta o uso ou no do produto
13
(HOLZINGER, 2005). Assim, de grande importncia que todo projetista de software no
esteja apenas ciente dos vrios mtodos de usabilidade, mas tambm esteja apto a determinar
rapidamente qual mtodo mais apropriado para cada situao em um projeto de software.
H ainda outras definies para usabilidade como a descrita no padro ISO 9241-11:
A efetividade, eficincia e satisfao com que usurios especficos atingem objetivos
especificados num ambiente particular.
Seffah et al. (2006) sugerem que a efetividade pode ser medida pela exatido, a
eficincia pelo tempo e a satisfao pelos parmetros subjetivos da carga de trabalho.
Para Preece (1993) usabilidade definida como uma medida da facilidade com que
um sistema pode ser aprendido ou usado, a sua segurana, eficcia e eficincia, e a atitude de
seus usurios para com ele. Esta definio no faz uma referncia explcita ao contexto de
utilizao ou de objetivos do usurio especificados e sugere que a usabilidade uma
"propriedade" de um sistema.
Essas definies consideram a usabilidade do ponto de vista terico.
Nielsen (1993) e Shneiderman (1998) tm uma definio mais prtica que est
descrita por meio de elementos mais especficos, sendo que a definio Shneiderman
essencialmente parecida com a de Nielsen divergindo na terminologia, como pode ser
observado no Quadro 1. Tanto Nielsen como Shneiderman no mencionam qualquer aspecto
relativo a utilidade (por exemplo, informaes sobre concluso de tarefas).
Dix (1998), por sua vez, define trs grandes grupos como fatores de usabilidade:
facilidade de aprendizado, flexibilidade e robustez. Os grupos so especificados por fatores
que influenciam o conceito a que pertencem. Por exemplo, a consistncia influencia na
facilidade de aprendizado, que subdivide-se em aspectos que so de natureza cognitiva.
Assim, mais controle dado sobre as habilidades cognitivas dos usurios.
Quadro 1 - Definio de usabilidade em diferentes fontes
ISO 9241-11 Shneiderman Nielsen
Eficincia Velocidade de desempenho Eficincia
Tempo de aprendizado Facilidade de aprendizado
Reteno por tempo Facilidade de memorizao
Eficcia Taxa de erros Taxa de erros
Satisfao Satisfao Satisfao
Em geral, concorda-se que cinco caractersticas essenciais de usabilidade devem fazer
parte de qualquer projeto de software:
14
" Capacidade de aprendizado, para que o usurio possa rapidamente comear a
trabalhar com o sistema;
" Eficincia, permitindo ao usurio que aprendeu a usar o sistema alcanar um alto
nvel de produtividade;
" Capacidade de memorizar, possibilitando que o usurio casual retorne ao
sistema depois de um perodo de no uso sem ter que reaprender tudo;
" Baixa taxa de erros, que leva os usurios a cometerem menos erros enquanto
usam o sistema e os erros cometidos so facilmente retificados, ou seja, no
ocorrem erros catastrficos;
" Satisfao, que compreende o conforto e a aceitabilidade, entendidos pelo usurio
como um sistema agradvel de usar.
Alguns desses critrios podem ser considerados mais importantes do que outros,
dependendo da situao a que forem aplicados. Em alguns casos, a eficincia em longo prazo
pode ter um grau de importncia suficientemente alto para que os desenvolvedores se
disponham a sacrificar a rpida capacidade de aprendizado (HOLZINGER, 2005).
Defensores desta abordagem engajam-se na anlise de tarefas e depois fazem
prottipos dos projetos da interface e conduzem testes de usabilidade com eles. No
fundamento desses testes, a tecnologia (idealmente) re-projetada ou (ocasionalmente) as
metas operacionais para o desempenho do usurio so revisadas (DILLON, 2000).
J o termo Engenharia de Usabilidade, em contraste com outros nomes de disciplinas
como Projeto da Interao (Interaction Design) ou Projeto Centrado no Usurio (User
Centered Design), visa descrever uma abordagem pragmtica para o projeto de interface do
usurio, a qual enfatiza mtodos empricos e definies operacionais dos requisitos do
usurio.
As vantagens da utilizao do projeto centrado no usurio trazem benefcios tanto
para o usurio como para o cliente: maior eficincia, maior produtividade, reduo de erros,
aumento de satisfao, menos treinamento, menos manuteno corretiva, maior aceitao,
menos custo de desenvolvimento e aumento nas vendas (RAJANEN; IIVARI, 2007).
A acessibilidade, por sua vez, significa no apenas permitir que pessoas com
necessidades especiais participem de atividades que incluem o uso de produtos, servios e
informao, mas a incluso e extenso do uso destes por todas as parcelas presentes em uma
determinada populao, com as mnimas restries possveis (MELO et al., 2006).
15
Em (FREIRE; RUSSO; FORTES, 2008), os autores afirmam que mesmo existindo
vrias guidelines e leis federais relacionadas acessibilidade, muitas pginas Web ainda tm
problemas de acessibilidade devido falta de conhecimento dos desenvolvedores sobre como
as pessoas com necessidades especiais usam a Web e devido falta de treinamento dos
mesmos desenvolvedores sobre os potenciais problemas de acessibilidade.
Com o objetivo de promover a acessibilidade no desenvolvimento de sistemas Web e
torn-los acessveis para um nmero maior de usurios foi criado o modelo WAI pelo W3C
que consiste em um conjunto de documentos compostos por guidelines para pessoas que
acessam a Web em condies especiais (ambientes, equipamentos) (LARA et al., 2010)
O termo acessibilidade utilizado neste trabalho envolve trs noes. A primeira
noo, o usurio, significa que nenhum obstculo deve ser imposto ao usurio face s suas
capacidades sensoriais e funcionais. A segunda, a situao, quer dizer que o sistema
acessvel e utilizvel em diversas situaes, independentemente do software, das
comunicaes ou dos equipamentos. E a terceira, o ambiente, implica em um acesso no-
condicionado pelo ambiente fsico.
Uma motivao para o desenvolvimento de sistemas multimodais tem sido o seu
potencial para expandir a acessibilidade dos computadores para usurios no especialistas, de
diferentes idades e nveis de conhecimento, com dificuldades sensoriais e motoras, alm de
disponibilizar novas formas de interao no disponveis no passado (GRUENSTEIN;
MCGRAW; BADR, 2008).
Uma interface multimodal pode ainda ser projetada para melhorar a acessibilidade e o
desempenho de usurios que tendem a ter dificuldades com interfaces de voz, por exemplo,
um usurio que no nativo em lngua inglesa interagindo com sotaque e tendo problemas
com os sistemas de reconhecimento de voz (JURAFSKY; MARTIN, 2000).
Interfaces multimodais podem ser projetadas para aumentar o desempenho em
circunstncias no ideais de interao, por meio da sugesto do uso de uma modalidade de
interao em resposta, por exemplo, ao aumento do nvel de rudo em um ambiente em que
est ocorrendo a interao por voz.
2.3 A usabilidade em sistemas multimodais
No ciclo do desenvolvimento de qualquer software, inclusive o multimodal, diversas
atividades de avaliao de usabilidade so realizadas durante as fases de projeto e
desenvolvimento com o intuito de melhorar a qualidade final do produto.
16
Componentes como os reconhecedores de voz e reconhecedores de gestos so
avaliados exaustivamente para verificar se o desempenho suficiente para a liberao do
produto. Um problema simples de reconhecimento, ou a falta de um requisito no produto
final pode acarretar um grande prejuzo para empresas que lidam com grandes quantidades de
usurios. Por exemplo, o Decreto n 6523, mais conhecido como a Lei do SAC (DECRETO
N 6.523, DE 31 DE JULHO DE 2008.) diz que a opo de falar com atendente deve ser
apresentada no incio da interao em uma interface de voz. Se esse requisito no for
considerado ou se o reconhecedor de voz no entender a solicitao do usurio, as empresas
podem ser multadas.
Para que os testes sejam realizados, prottipos e verses preliminares de sistemas so
gerados e simulaes so executadas por avaliadores de usabilidade (OVIATT, S., 2003).
Porm, muitas vezes o protocolo de testes e as mtricas estabelecidas so desenvolvidos sob
demanda e com recursos limitados, diferentes aspectos de qualidade so avaliados com
diferentes critrios de avaliao.
Uma das solues considerar o uso de Design Rationale (DR) na fase de avaliao
de usabilidade e estabelecer o protocolo de testes na fase de obteno de requisitos.
A taxonomia para avaliar a qualidade de servio e a qualidade da experincia proposta
em (MOLLER et al., 2009) pode ser utilizada durante essas duas fases para viabilizar a coleta
de informao necessria no contexto do projeto de interfaces multimodais, pois considera
aspectos importantes de qualidade e de acordo com o padro ISO 9126, a usabilidade um
dos seis aspectos de qualidade de software (BHATTI, 2005).
Na abordagem proposta nesta tese, o projeto para a usabilidade o foco central nas
fases de projeto, desenvolvimento e testes. No entanto, muitas empresas e muitos mtodos
encontrados na literatura no consideram e no incorporam a usabilidade em seus processos.
Quando um teste apresenta indicaes de que existe a necessidade de melhoria da
usabilidade, necessrio localizar o que precisa ser corrigido e como corrigir. A correo de
um problema pode ter um impacto positivo em um indicador de usabilidade e negativo em
outro, portanto necessrio que o projetista utilize o raciocnio capturado e armazenado em
projetos anteriores para julgar porque e como o problema deve ser corrigido.
A eficincia do uso de tcnicas como guidelines, princpios, etc, est diretamente
relacionada com o tipo de avaliao que vai ser conduzida, como ser discutido mais adiante
neste captulo.
17
2.4 Um modelo em camadas para obteno de requisitos considerando
usabilidade
As diferentes tcnicas, definies e princpios tornam a usabilidade um conceito de
difcil interpretao, tanto no projeto de um novo sistema como na realizao de manutenes
ou na criao de novos projetos num mesmo domnio j conhecido e explorado.
Normalmente, os autores despendem muito esforo para identificar qual o melhor
conjunto de princpios ou para definir um conjunto completo de heursticas. Apesar desse
conjunto importante de tcnicas, como guidelines, princpios e padres de projeto estarem
disponveis, ainda no est claro como elas se relacionam e como escolher uma tcnica para
melhorar a usabilidade.
A Figura 3 mostra um modelo de camadas de usabilidade (VEER; WELIE, 2000)
(WELIE; VAN DER VEER; ELINS, 1999) que ajuda a compreender os diferentes
conceitos durante a fase de anlise de requisitos.
No mais alto nvel, est a definio ISO de usabilidade que dividida em trs
aspectos: eficincia, eficcia e satisfao. Este nvel uma maneira abstrata de interpretar a
usabilidade e no diretamente aplicvel na prtica. No entanto, fornece trs pilares que so
fundamentados em uma teoria bem definida para a usabilidade (BHATTI, 2005).
O prximo nvel contm uma srie de indicadores de utilizao, que so indicadores
do nvel de usabilidade que pode realmente ser observado na prtica quando os usurios esto
no ambiente de trabalho. Cada um desses indicadores contribui para os aspectos abstratos do
nvel superior. Por exemplo, uma baixa taxa de erro contribui para uma maior eficcia e
rapidez e um bom desempenho indica uma boa eficincia. O nvel desejado para cada um dos
indicadores de utilizao depende da natureza do sistema. Para um sistema em produo,
eficincia pode ser a meta principal, mas para um site multimodal a satisfao pode ser muito
mais importante do que a eficincia.
O terceiro o nvel dos meios que so utilizados nas heursticas para melhorar um ou
mais dos indicadores de utilizao. Por exemplo, a consistncia pode ter um efeito positivo
sobre a facilidade de aprendizado. Por outro lado, alta adaptabilidade pode ter um efeito
negativo de memorizao, tendo um efeito positivo no desempenho. Assim, cada meio pode
ter um efeito positivo ou negativo sobre alguns dos indicadores. Cabe ao projetista encontrar
os melhores nveis para cada meio. Para fazer isso, o projetista deve usar os trs domnios do
conhecimento (seres humanos, interao e trabalho) para determinar os nveis adequados dos
indicadores, e o conhecimento de projeto deve incorporar o raciocnio de como as mudanas
na utilizao dos meios afetam os indicadores de utilizao.
pretende trabalhar em um determinado momento do projeto (usurio,
Figura
2.5
Janelas, cones, Menus, Ponteiros (WIMP em ingls)
foram estabelecidos com base na consistncia percebida pelo usurio com a interao entre
projetos diferentes e na interpretao de um comportamento intuitivo, result
de projeto bem entendidos e metforas que podem ser aplicadas independentemente do
sistema
interao com a aplicao em diversas outras
interface com o objetivo de pautar o projeto e permitir a descoberta de problemas de
usabilidade. Os quatro princpios, segundo
Captulo 2
O ltimo nvel usado para determinar o domnio de conhecimento que o projetista
Figura 3 - Modelo em
Princpios e
Os paradigmas de interface que so bem sucedidos atualmente, por exemplo, o
sistema (SERRANO
Essas metforas permitem que o usurio aplique o conhecimento adquirido em sua
Por trs desses paradigmas foram estabelecidos alguns princpios de bons projetos de
" Visibilidade
" Bom
Captulo 2 - A usabilidade
Modelo em camadas
Princpios e guidelines
(SERRANO et al., 2008)
Visibilidade e propriedades percebidas de um objeto (
Bom modelo conceitual
A usabilidade no projeto de interfaces multimodais
camadas para usabilidade
guidelines para o projeto de interfaces multimodais
, 2008).
e propriedades percebidas de um objeto (
modelo conceitual (entendimento do funcionamento do sistema),
no projeto de interfaces multimodais
18
para usabilidade, traduzido de
para o projeto de interfaces multimodais
interao com a aplicao em diversas outras tarefas em sistemas diferentes.
usabilidade. Os quatro princpios, segundo (NORMAN,
(entendimento do funcionamento do sistema),
, traduzido de
Janelas, cones, Menus, Ponteiros (WIMP em ingls) e o arrastar e soltar (
tarefas em sistemas diferentes.
NORMAN, 1995) so:
no projeto de interfaces multimodais centrado no usurio
pretende trabalhar em um determinado momento do projeto (usurio, interao ou trabalho).
, traduzido de (VEER; WELIE, 2000)
e o arrastar e soltar (
so:
e propriedades percebidas de um objeto (affordance
centrado no usurio
interao ou trabalho).
(VEER; WELIE, 2000)
e o arrastar e soltar (drag and drop
projetos diferentes e na interpretao de um comportamento intuitivo, result ando em padres
affordance),
centrado no usurio
interao ou trabalho).
(VEER; WELIE, 2000).
para o projeto de interfaces multimodais Web
drag and drop),
ando em padres
19
" Bons mapeamentos (relacionamento entre as entradas e sadas de uma
interface)
" Retorno ou feedback (retornar ao usurio informao sobre as aes que
foram feitas).
Com base nessa particularidade presume-se que as interfaces multimodais tambm
necessitam estar fundamentadas em um conjunto de princpios, para facilitar o projeto de
sistemas multimodais e porque elas integram vrias modalidades de interao com o usurio.
Dessa forma, novas metforas podero se manifestar nas aplicaes e nas interfaces
nas quais elas desempenharo o papel de integrar as entradas do usurio, que podem ocorrer
de diversos modos, e na sntese de sada de dados na forma de mltiplas mdias.
Um desafio para desenvolver uma aplicao de qualidade que contenha interao por
voz usar o tempo de maneira eficiente e no obrigar o usurio a ouvir mais do que ele
precisa ouvir para entender a mensagem, responder de forma sucinta e conseguir interagir
com o sistema.
De acordo com (RAMAN, 2003) existem cinco princpios que devem ser
considerados durante o projeto das interfaces multimodais: sincronizao, transio,
compartilhamento do estado de interao, previsibilidade e adaptatividade.
Guidelines (diretrizes) tambm so importantes no projeto de interfaces, pois
orientam os projetistas na tomada de decises consistentes atravs dos elementos que
constituem o produto. Em (REEVES et al., 2004) os autores propem a utilizao de cinco
guidelines para o projeto de interfaces multimodais: projeto da entrada e sada multimodal,
adaptatividade, consistncia na interao, retorno (feedback) e tratamento e preveno de
erros.
Em geral, os princpios e guidelines costumam ser genricos e no triviais. A
experincia fundamental para que o projetista ou o avaliador saiba distinguir quando aplicar
e quando ignorar um princpio em determinado projeto.
Por essa razo, no Captulo 4 ser proposta a utilizao de dez princpios definidos
com base na teoria pesquisada nesta seo, como uma forma de facilitar a identificao de
problemas de usabilidade na interao multimodal e tambm visando explicitar boas prticas
em nvel de projeto que sejam identificados por seus projetistas.
20
2.6 Padres de Projeto para interfaces multimodais
Alm dos princpios e das guidelines, existe uma tcnica utilizada para representar e
comunicar o conhecimento de projeto em IHC, os padres de projeto (JOHN W. STAMEY;
HONEYCUTT, 2004).
Padres de projeto (Design Patterns) foram utilizados primeiramente no domnio da
arquitetura (ALEXANDER; ISHIKAWA; SILVERSTEIN, 1977) para representar solues
de sucesso para problemas recorrentes encontrados nesse contexto.
Um padro pode ser entendido como uma abordagem para capturar e apresentar
conhecimento de projeto na resoluo de problemas, atuando como um meio de divulgao
de conhecimento entre projetistas especialistas e novatos e de comunicao entre os
elementos da equipe.
(BARFIELD et al., 1994), (BORCHERS, 2001) e (TIDWELL, 2005) afirmam em
seus trabalhos que os padres para interao diferem dos propostos por Alexander (1977) em
um tpico importante: o tempo. Os padres de Alexander lidam exclusivamente com
configuraes espaciais. A IHC, por outro lado, deve levar em considerao que a interface
com o usurio em um sistema computacional interativo um ambiente dinmico que
freqentemente muda de aparncia e comportamento durante o processo da interao
(BORCHERS, 2001).
Um dos desafios para o domnio de IHC encontra-se no desenvolvimento de tcnicas
eficientes para documentar e comunicar o conhecimento que os projetistas adquiriram e
aplicaram em determinadas circunstncias (TIDWELL, 2005).
Segundo Borchers (2001), esse conhecimento precisa ser aplicado em diversos
contextos, tais como:
" Durante o processo, quando o projetista procura uma soluo para um problema.
" Durante a formao de equipes para o projeto.
" Durante a incluso de novos membros na equipe do projeto.
" Na comunicao entre as equipes multidisciplinares e com os usurios.
" Na disseminao da soluo.
Tidwell (2005) argumenta que os padres so as melhores alternativas para se
expressar as guidelines e princpios disponveis no domnio da IHC. As guidelines para o
projeto de uma interface grfica (GUI) so exemplos tpicos que so utilizados para assegurar
um visual comum a todas as interfaces geradas atravs de uma ferramenta computacional,
mas que tornam o projeto dependente da tecnologia disponvel no momento, perdendo a
21
aplicabilidade caso haja alguma mudana tecnolgica, por exemplo, a migrao de interfaces
entre diferentes sistemas operacionais, ou at mesmo a incluso de uma nova modalidade de
interao.
A utilizao de padres ao invs das guidelines motivo de muita discusso na
comunidade de IHC. O que se verificou durante essa pesquisa foi que a proposta das
guidelines capturar conhecimento de projeto em regras pequenas, que podem ser usadas
depois, no projeto de novas interfaces. A proposta dos padres capturar conhecimento
(valores e idias) de projeto validado cientificamente e descrev-lo em problema, contexto,
soluo e raciocnio.
A utilizao dos padres implica em uma nfase no processo de desenvolvimento e o
uso de guidelines no produto (uma lista de diretivas imperativas). Um bom padro tem que
ser evoludo da experincia tanto do sucesso quanto da falha e observaes de um conjunto
de desenvolvedores ao invs de gravar muitos exemplos, deve ser feito um refinamento para
garantir a invarincia.
Uma linguagem de padres (BORCHERS, 2001) atravs da sua organizao inter-
relacionada permite um caminho de navegao entre as diversas guidelines com segurana e
a possibilidade de envolver os usurios de interfaces no projeto e modificao desses
artefatos, servindo como uma linguagem de comunicao entre os participantes do projeto.
Quando se fala de ponto de vista do usurio, importante dar nfase argumentao
de como e porque a usabilidade pode ser melhorada. Sem esse raciocnio impossvel ver
quando e porque a soluo realmente boa e aceitvel.
Algumas solues resolvem os problemas dos projetistas, mas no necessariamente os
do usurio. De acordo com Welie (2000), no difcil identificar padres na interface com o
usurio, mas difcil identificar os padres que realmente beneficiam o usurio e explicam os
aspectos de usabilidade do sistema em questo atravs de indicadores como: aprendizagem,
memorizao, desempenho, taxa de erro, satisfao e finalizao da tarefa.
Na Figura 4, mostrado o padro de IHC Home Link (WELIE, 2010) que mostra a
importncia de ter um logotipo direcionando o usurio para a pgina principal do site.
O trabalho descrito em (RATZKA; WOLFF, 2006) prope uma metodologia de
projeto que utiliza padres de projeto para o desenvolvimento de sistemas multimodais
interativos, destacando questes de projeto relacionadas ao contexto de fatores de utilizao e
como um meio de orientar o processo de anlise e projeto. Os padres de projeto so
discutidos como uma ferramenta de modelagem em geral, bem como uma possvel
abordagem para a criao de sistemas multimodais. A concepo dos sistemas multimodais
rene uma ampla variedade de mtodos de anlise (tarefa,
autores afirmam que a combinao de modalidades, bem como os novos dispositivos de
interao implicam um elevado grau de liberdade
em padres
multimodal como forma de documentar e divulgar as solues bem sucedidas para os
problemas recorrentes de projeto no contexto da interao em sistema
Exemplos de padres multimodais identificados nesta pesquisa podem ser encontrados no
Apndice A
2.7
usabilidade deve ser
quando os mtodos de inspeo ou de testes so iniciados no final do ciclo do projeto, as
mudanas nas interfaces podem ser caras e difceis de implementar e gerenciar. Quanto mais
cedo os
usadas com o objetivo principal de corrigir problemas tcnicos e informar ao projetista
Captulo 2
padres multimodais.
Neste trabalho prope
Apndice A.
Avaliao de
Um dos conceitos fundamentais da Interao Humano
usabilidade deve ser
cedo os erros forem detectados, mais fcil ser corrigi
Durante as etapas de um projeto de software diversas formas de avaliaes podem ser
Captulo 2 - A usabilidade
multimodais.
Figura 4 - Padro de IHC
Neste trabalho prope
Avaliao de usabilidade
usabilidade deve ser considerada em etapas anteriores ao incio do desenvolvimento, pois
erros forem detectados, mais fcil ser corrigi
A usabilidade no projeto de interfaces multimodais
Padro de IHC
Neste trabalho prope-se a identificao de padres de projeto para a interao
sabilidade em
considerada em etapas anteriores ao incio do desenvolvimento, pois
22
interao implicam um elevado grau de liberdade e
Padro de IHC Home Link
se a identificao de padres de projeto para a interao
em interfaces
rene uma ampla variedade de mtodos de anlise (tarefa, contexto, dados do usurio). Os
e so tpicos
Home Link (WELIE, 2010)
nterfaces multimodais
erros forem detectados, mais fcil ser corrigi-los (MARCUS, 2002)
no projeto de interfaces multimodais centrado no usurio
contexto, dados do usurio). Os
so tpicos que devem ser considerados
(WELIE, 2010)
ultimodais
Um dos conceitos fundamentais da Interao Humano-Computador que a
(MARCUS, 2002)
centrado no usurio
que devem ser considerados
(WELIE, 2010)
problemas recorrentes de projeto no contexto da interao em sistemas multimodais.
Computador que a
(MARCUS, 2002).
centrado no usurio
que devem ser considerados
s multimodais.
Computador que a
23
problemas de interao e usabilidade que podem afetar a experincia do usurio e diminuir
sua satisfao no uso do produto.
Os mtodos clssicos de avaliao de usabilidade foram estabelecidos no sculo
passado, principalmente na dcada de 80, quando o principal objetivo era avaliar e melhorar a
usabilidade de aplicaes desktop que eram utilizadas em ambientes semelhantes, geralmente
o ambiente de trabalho, na sua maioria por usurios com o mesmo perfil de uso. O objetivo
principal das avaliaes era aumentar a produtividade com a realizao rpida, eficiente e
fcil das tarefas.
Os mtodos para a avaliao de interfaces convencionais podem ser divididos em 2
grupos:
" Os analticos, fundamentados na teoria e que no necessitam de um sistema
funcional nem de usurios reais;
" Os empricos, fundamentados em dados reais obtidos da interao entre um
usurio e um prottipo do sistema.
Exemplos de mtodos analticos incluem a avaliao heurstica baseada na lista de dez
heursticas definidas por Jacob Nielsen (NIELSEN; MOLICH, 1990; NIELSEN, 1993), o
GOMS (CARD; NEWELL; MORAN, 1983) e o mtodo Cognitive Walkthrough (LEWIS et
al., 1990).
O principal benefcio permitir a avaliao de uma interface nos estados iniciais de
projeto e desenvolvimento. No entanto, o fato de depender de dados hipotticos e de teorias
faz com que esses mtodos sejam pouco precisos ou limitados quando o escopo de estudo
interao multimodal, que ainda no apoiada por uma base terica consolidada. Alm disso,
a configurao de experimentos e a interpretao dos dados desses mtodos so tarefas
complexas e consomem muito tempo e recursos, muitas vezes inviabilizando a avaliao.
Em contraste, os mtodos empricos usam dados obtidos da observao de usurios
reais executando tarefas e interagindo com um sistema, geralmente prottipo do sistema final,
mock-ups ou cenrios.
Um exemplo o Teste com Usurios. Esse mtodo de avaliao de usabilidade
realizado com a participao de usurios, executando-se tarefas definidas pelos avaliadores e
projetistas de interface, que observam as atitudes dos usurios diante da interface analisada
(NIELSEN, 1993).
Hoje em dia, com o grande nmero de dispositivos existentes aliado ao avano
exponencial do acesso Internet por diferentes perfis de usurios que executam diferentes
24
tipos de tarefas em diferentes ambientes (PATERNO; GIAMMARINO, 2006; PATERN;
SANTOS, 2007), faz-se necessria a pesquisa por diferentes formas de avaliaes de
usabilidade que proporcionem a identificao de problemas tanto para tarefas rotineiras e
simples como tambm para tarefas complexas e de alto risco.
Essa caracterstica de um cenrio variado de utilizao das interfaces por diferentes
perfis de usurios em diferentes ambientes com novos dispositivos fortalece a tese de que as
interfaces multimodais so uma boa escolha para aumentar a satisfao do usurio e sua
experincia geral de uso devido a sua caracterstica de proporcionar uma interao mais
natural, flexvel e eficiente de uma maneira mais prxima ao modo como as pessoas se
comunicam naturalmente.
Os mtodos de avaliao de usabilidade devem tambm considerar, investigar e
proporcionar formas de resoluo para os problemas que podem ocorrer devido ao local onde
o usurio est interagindo e sua situao momentnea, por exemplo, estar distrado em um
ambiente ruidoso ou estar executando mltiplas tarefas ao mesmo tempo.
Outro fator interessante levantado por (KJELDSKOV; GRAHAM, 2003) em um
estudo que compara os mtodos usados em pesquisas de IHC em ambientes multimodais,
aponta que a maioria dos estudos (55%) so pesquisas aplicadas e 33% so pesquisas de
laboratrio, mas apenas 3% so estudos de campo, o que sugere que existe uma tendncia de
no se considerar o ambiente em que o usurio comumente interage durante as avaliaes,
fator esse que pode prejudic-las. Esse fato pode ser justificado pelo alto custo e necessidade
de um alto nmero de recursos inerentes aos mtodos de pesquisa de campo.
Portanto, os trs fatores relacionados ao contexto de uso, que foram apresentados
neste captulo, devem ser levados em considerao durante o processo de avaliao, pois
podem influenciar na usabilidade final do produto:
" o contexto fsico, ou o lugar onde o usurio interage.
" o contexto tecnolgico, tecnologia disponvel ao usurio (rede, dispositivos de
IO).
" o contexto social, representando todas as situaes que influenciam o uso do
sistema.
Nesta tese, descrevem-se os mtodos mais apropriados para a avaliao de interfaces
multimodais, categorizando-os segundo a definio de (BERNHAUPT, 2008), bem como as
modificaes e extenses que se sugere para uma maior eficincia dos mesmos, levando-se
25
em considerao a premissa de Desurvire (1994) que os pontos fracos de alguns mtodos so
superados com o uso de outros mtodos.
A avaliao em interfaces multimodais pode ser realizada com qualquer dos mtodos
citados a seguir, levando-se em considerao as caractersticas dessas interfaces. O objetivo
das avaliaes de usabilidade no somente identificar problemas de usabilidade, mas
tambm fornecer um mecanismo eficiente para se reportar os erros equipe de projeto e at
mesmo fornecer sugestes de alterao de projeto ou implementao.
Testes com usurios:
Os testes com usurios so conduzidos geralmente em laboratrio e envolvem
usurios que executam tarefas tpicas e so orientados a "pensar alto", ou seja, falar o que
pensam quando interagem com o sistema.
O sistema alvo do teste pode ser o sistema real totalmente funcional, um prottipo
executvel ou uma configurao Wizard of Oz (TAIB; RUIZ, 2007), na qual as
funcionalidades multimodais so simuladas por uma pessoa. O desempenho dos usurios
observado e medido em termos de soluo de problemas, tarefas completadas, erros
observados, nmero de clicks e teclas pressionadas.
As observaes podem ser realizadas pelos pesquisadores, por cmeras ou por meio
da anlise dos logs das aes executadas no sistema. Essa avaliao de aplicaes
multimodais em laboratrio pode no ser suficiente, pois para se investigar o real contexto de
uso, testes de campo ou em situaes reais so necessrios para se verificar possveis
problemas no uso das interfaces em diferentes contextos, como em ambientes com rudo ou
usando dispositivos mveis.
A maioria dos estudos de usabilidade para interfaces multimodais encontrados na
literatura adota como mtodo preferido os testes com usurios (BERNHAUPT, 2008;
CHANG; BOURGUET, 2008; NETO; FORTES, 2009) no qual as tarefas executadas por
usurios reais so observadas ou gravadas, pois permite a observao e a investigao de
como os usurios interagem com as interfaces multimodais fornecendo informaes teis
sobre usabilidade e experincia de uso.
Mais adiante nesta tese ser apresentado um estudo de caso utilizando testes com
usurios com anlise de logs e uso de questionrio que foi projetado para considerar as
necessidades inerentes s interfaces multimodais.
Mtodos de inspeo:
Os mtodos de inspeo envolvem especialistas no domnio e em avaliaes de
usabilidade com mtodos analticos que conhecem e utilizam guidelines ou recomendaes
26
especficas para identificar e julgar problemas de usabilidade fundamentado em sua
experincia em outros projetos e at mesmo no desenvolvimento de interfaces.
Os mtodos analticos so conhecidos por serem fceis, rpidos e baratos, mas
requerem pessoas especialistas e treinadas, pois os resultados dependem do conhecimento e
da experincia de tais especialistas (NIELSEN, 1995). Mtodos desta categoria incluem:
avaliao heurstica, reviso de guidelines, percurso pluralstico, inspees de consistncia,
percurso cognitivo, entre outros.
Mtodos de inspeo podem ser aplicados nas primeiras etapas do processo de
desenvolvimento com a anlise de mock-ups, cenrios e prottipos. A falta de experincia e
conhecimento especfico dos especialistas no domnio multimodal e a falta de guidelines que
considerem as modalidades e suas combinaes durante a interao podem explicar porque
esses mtodos tm sido usados menos frequentemente em projetos multimodais.
A avaliao heurstica (NIELSEN, 1995) utilizada para realizar inspees
sistemticas da interface que est sendo desenvolvida com relao sua usabilidade.
Basicamente avaliadores experientes interagem com a interface e julgam a sua adequao
comparando-a com princpios de usabilidade reconhecidos: as heursticas. Mais adiante ser
apresentado como esse mtodo pode ser adaptado para ser utilizado com as peculiaridades
das interfaces multimodais, por meio do uso de guidelines especficas que foram obtidas em
estudos de caso utilizando-se DR.
A modificao dos Mtodos de Inspeo para incluir guidelines e conhecimento
especfico do domnio multimodal ajudam os avaliadores a aproveitarem as vantagens desses
mtodos e a reduzirem seus pontos fracos.
Pesquisas e questionrios:
um mtodo bastante conhecido e extensivamente empregado para obteno de
feedback qualitativo dos usurios (satisfao de uso, preferncias de modalidade, etc), mas
pouco usado at ento para avaliaes em interfaces multimodais, porm so muito teis para
investigar o contexto de uso dos dispositivos e das interfaces em sistemas multimodais. O
usurio interage com os dispositivos em tarefas cotidianas e ao mesmo tempo reporta suas
experincias, problemas e sugestes para a melhoria das interfaces e da interao.
Frequentemente questionrios so usados em conjunto com outros mtodos de avaliao de
usabilidade para apresentar melhores resultados.
Mtodos de modelagem:
Em complemento aos mtodos centrados em usurios, especialistas e pesquisas
existem os mtodos de modelagem tradicionalmente aplicados no domnio de engenharia de
27
software como testes automticos, descries formais, anlise de incidentes e modelos de
tarefa.
Os mtodos de modelagem complementam os tradicionais mtodos de avaliao,
fornecendo informaes da especificao formal do software e so teis no contexto
multimodal, pois as diferentes modalidades e suas combinaes de uso podem ser testadas
automaticamente, por meio de selees no modelo.
Mais recentemente, as simulaes (OVIATT, S., 2003) e os mtodos de modelagem
para checagem de especificaes de sistemas (CHANG; BOURGUET, 2008) tm sido
utilizados para prever problemas de usabilidade, tais como, estados que no so alcanados,
deteco de conflitos de modalidades, eventos necessrios para fuso e fisso de
modalidades.
Patern e Santos (PATERN; SANTOS, 2007) propem combinar anlise de tarefas
no modelo com gravaes de vdeo e eye tracking para melhor entender a interao.
Bernhaupt (2008) e Chang (2008) usam tcnicas de especificao formal em
combinao com os mtodos tradicionais de avaliao de usabilidade, como testes com
usurios e cognitive walkthrough para uma detalhada verificao e anlise de problemas de
usabilidade relacionados aos eventos necessrios para fuso e fisso de modalidades.
2.8 Consideraes finais
Neste captulo foram apresentados os referenciais tericos que sero utilizados para a
proposta da abordagem para projeto, desenvolvimento e testes de interfaces multimodais
Web, que ser introduzida no Captulo 4 .
A seguir, no Captulo 3, sero discutidos o estado da arte na rea de interao
multimodal e as diversas abordagens e frameworks que tm sido propostos para realizar a
atividade de projeto, os quais serviro como base para a proposta do ambiente de autoria de
interfaces multimodais Web apresentados nesta tese.
Captulo 3 - Projeto de Interfaces Multimodais
29
Captulo 3. Projeto de Interfaces
Multimodais
O advento dos sistemas multimodais representa um movimento de pesquisas do
paradigma de interao convencional do tipo janela, cone, menu e dispositivo de
apontamento (traduo para Window Icon Menu Pointing - WIMP), para pesquisas com um
novo paradigma que tem como objetivo fornecer aos usurios: maior poder de expresso,
naturalidade, flexibilidade e portabilidade no uso de interfaces mais intuitivas e naturais
(SCHAPIRA; SHARMA, 2001).
Os requisitos de integrao e de sincronizao para combinar estrategicamente as
diferentes modalidades em sistemas completos constituem um novo tema de pesquisa para os
sistemas multimodais que comearam a se definir no final da dcada de 90 (OVIATT;
DEANGELI; KUHN, 1997).
Isto significa que o projeto bem sucedido de um sistema multimodal requer a
orientao da cincia cognitiva na coordenao da percepo humana e na produo de
interfaces que utilizem modalidades naturais ao usurio (OVIATT; COULSTON;
LUNSFORD, 2004).
Sabe-se que os usurios apreciam poder interagir de maneira multimodal com os
sistemas, mas no o fazem sempre assim (OVIATT; COULSTON; LUNSFORD, 2004). Seus
padres naturais de comunicao envolvem misturar expresses de uma modalidade e
expresses previsveis de outras modalidades baseadas no tipo de ao que est sendo
executada.
Resultados empricos (OVIATT, 1997; OVIATT; DEANGELI; KUHN, 1997)
enfatizam que os sistemas multimodais necessitam distinguir entre quando os usurios esto e
no esto se comunicando de maneira multimodal, de forma que as decises corretas possam
ser feitas no momento em que as entradas de informao paralelas forem interpretadas
conjuntamente ou individualmente.
Estes dados tambm sugerem que o conhecimento do tipo de aes a serem includas
em uma aplicao deve influenciar a deciso sobre construir um sistema multimodal ou no.
30
Neste captulo so apresentados: o estado da arte na rea de interao multimodal e as
diversas abordagens que tm sido propostas para realizar a atividade de projeto de aplicaes
que incorporem interao multimodal.
Na Seo 3.2 so feitas algumas consideraes sobre o uso de interao por voz em
sistemas multimodais e na Seo 3.3 apresentam-se as caractersticas das linguagens de
programao que habilitam o desenvolvimento de sistemas multimodais. Na Seo 3.4 so
mostradas as abordagens e frameworks existentes na literatura para o projeto de interfaces
multimodais. Conclui-se o captulo na Seo 3.5, com as consideraes finais.
3.2 O uso de interao por voz em sistemas multimodais
importante considerar que embora as interaes por interfaces de voz e por
interfaces grficas com manipulao direta possam ser sincronizadas durante a interao
multimodal, sincronismo no implica em simultaneidade (DUMAS; LALANNE; OVIATT,
2009).
Quando a interao por voz utilizada, uma segunda modalidade considerada til se
o sinal de fala est degradado em um ambiente ruidoso, por exemplo. Nesse caso ela pode
fornecer a informao necessria quando a confiana associada ao reconhecimento de voz
baixa.
As entradas baseadas em apontamento ou caneta precedem as entradas por fala em
90% dos comandos multimodais seqenciais, e na maioria das simultneas tambm (COHEN
et al., 1997). Portanto, a fala no nem a portadora exclusiva de contedo importante, nem
tem a precedncia temporal sobre outras modalidades de entrada.
O oferecimento adiantado de entrada manual pode ser considerado como um
fornecedor de contexto, e tambm pode dar assistncia aos usurios enquanto planejam sua
fala. Quando livres para interagir de forma multimodal, os usurios eliminam seletivamente
muitas complexidades da fala, por exemplo, quando um usurio diz: Adicione um quadrado
no canto superior esquerdo da tela ou de maneira mais simplificada, quando o usurio
aponta o local desejado na tela e diz Adicione um quadrado.
A linguagem multimodal diferente da forma tradicional da linguagem natural, e em
muitos casos ela simplificada substancialmente. Uma implicao que a linguagem
multimodal pode ser mais fcil de processar e poderia suportar sistemas mais robustos no
futuro.
31
Em uma comunicao humana, linguistas verificaram que a fala espontnea e
gesticular no envolve informao duplicada (OVIATT, 1999a), destacando a importncia da
complementaridade como um tema importante durante uma comunicao multimodal. Os
projetistas de sistemas multimodais no devem conseqentemente confiar na suposio de
que uma informao duplicada ao processar um comando multimodal.
um erro pensar que todos os usurios interagem com um sistema multimodal de
maneira uniforme, sempre utilizando os mesmos comandos e modalidades em um
determinado momento (OVIATT, 1999b). Tais sistemas devem ser projetados para detectar e
se adaptar ao padro de interao de cada usurio e, conseqentemente, melhorar
consideravelmente as taxas de erro de reconhecimento.
H outras vantagens na utilizao dos sistemas multimodais com o uso de voz do que
simplesmente a velocidade de interao, pois esses sistemas permitem evitar erros
substanciais e uma recuperao de erro mais fcil, como discutido previamente. Por exemplo,
os erros crticos de tarefa e os erros de linguagem no fluente podem diminuir de 36% a 50%
durante a interao multimodal (OVIATT, 1997).
Uma vantagem mais significativa a flexibilidade que os sistemas multimodais
permitem aos usurios em selecionar e em alternar entre modalidades de entrada. Tal
flexibilidade torna possvel aos usurios alternarem modalidades de modo que a sobrecarga
fsica seja evitada na utilizao de uma delas (PATERN; SANTOS, 2007).
As interfaces multimodais com interao por voz podem acomodar uma grande gama de
usurios, tarefas, e ambientes incluindo os usurios que esto com algum sentido
temporariamente ou permanentemente comprometido, ou quando esto usando um
dispositivo mvel, e outros casos em que uma modalidade pode no ser suficiente (HUBERT,
2006; PATERNO; GIAMMARINO, 2006).
3.3 Tecnologias para o desenvolvimento de interfaces multimodais para a
Web
O World Wide Web Consortium (W3C) fundado em 1994 tem se mostrado ativo na
pesquisa e desenvolvimento de linguagens para o desenvolvimento baseado na Web. Dois de
seus grupos, o Voice Browser e o Multimodal Interaction, so responsveis pela padronizao
de linguagens para o desenvolvimento de aplicaes de voz e multimodais (JOHNSTON,
2009).
32
A vantagem das linguagens padronizadas, alm do reso e da portabilidade, que o
desenvolvedor no precisa conhecer os detalhes tecnolgicos de como os sistemas de
reconhecimento funcionam, economizando tempo e esforo.
O W3C vem padronizando linguagens para o desenvolvimento de aplicaes
multimodais como o SALT e o XHTML + Voice (X+V) e tambm publicou recentemente a
linguagem EMMA para a representao de informaes semnticas fornecidas pelo usurio
atravs de teclado, mouse, microfone, etc.
Na seo a seguir ser apresentada a linguagem VoiceXML que impulsionou as
pesquisas pelas linguagens multimodais apresentadas na seqncia.
3.3.1 VoiceXML
VoiceXML (2007) uma linguagem de marcao cujo objetivo fornecer aos
desenvolvedores de aplicaes com interao por voz a possibilidade de descrever os
elementos de dilogo e minimizar as requisies entre o cliente e o servidor por meio da
especificao de mltiplas requisies por documento XML (W3C, 1996). A linguagem
VXML inclui elementos para permitir a sada de voz sintetizada (TTS) ou a sada por meio de
arquivos de udio, alm de permitir o reconhecimento de entrada por voz, por DTMF ou
entrada previamente gravada. Inclui tambm as caractersticas dos sistemas de telefonia como
transferncia de chamada e desconexo. O Quadro 2 resume os elementos da linguagem
VXML, alocando-os ao escopo de seus respectivos objetivos.
Quadro 2 - Principais elementos da linguagem VXML organizados por escopo
Escopo Elementos (Tags) VXML
Variveis e propriedades <assign>, <meta>, <param>, <property>, <script>, <value>, <var>,
<clear>
Sntese de fala e sada de udio <audio>, <block>, <enumerate>, <reprompt>, <sayas>, <break>
Tratamento de erros <catch>, <throw>, <error>, <help>, <noinput>, <nomatch>
Fluxo do dilogo <choice>, <elseif>, <form>, <goto>, <exit>, <subdialog>,
<submit>, <else>, <link>, <return>, <menu>, <option>, <if>
Entradas de usurios e gramticas <field>, <dtmf>, <record>, <filled>, <grammar>
Integrao com sistemas de telefonia <transfer>, <disconnect>
Definio de documento <vxml>, < initial>, <object>
Existem diversas ferramentas para desenvolvimento de aplicaes em VoiceXML
como, o WebSphere Voice Toolkit da IBM e o Nuance Development Framework da Nuance
Communications Inc, que oferecem os componentes necessrios para o desenvolvimento de
aplicaes complexas sem a necessidade de conhecer a tecnologia de voz por completo. Essas
33
ferramentas oferecem caractersticas essenciais para o desenvolvimento de aplicaes de voz
como:
" Suporte para o projeto grfico do fluxo de comunicao.
" Auxlio no desenvolvimento de cdigo VXML e verificao de erros em cdigo.
" Auxlio no desenvolvimento de gramticas e verificao de erros.
3.3.2 SALT
SALT (Speech Application Language Tags) uma linguagem de marcao
desenvolvida pelo Salt Forum, originalmente formado por Cisco, Comverse, Intel, Microsoft,
Philips, e ScanSoft, para o desenvolvimento de aplicaes multimodais que usam a entrada e
a sada de voz (reconhecimento e sntese de voz), reconhecendo e gerando falas humanas
(SWADE; REUSCH, 2007).
Como linguagem de marcao, SALT fornece tags que especificam o que o software
de reconhecimento de voz deve escutar e o que o software de sntese deve dizer. Enquanto o
X+V, que ser apresentado mais adiante, combina XHTML, VoiceXML e XML Events para
criar aplicaes multimodais, o SALT um conjunto de tags de baixo nvel para especificar a
interao por voz que pode ser inserida em qualquer ambiente. Ou seja, SALT requer um
ambiente para ser executado, mas no define esse ambiente, fazendo com que o
desenvolvedor tenha que gerar diferentes verses da aplicao para cada ambiente de
execuo. Em contraste, X+V define todos os aspectos do ambiente da aplicao e assegura
consistncia e portabilidade entre diferentes ambientes.
A necessidade desse ambiente externo torna necessrio gerar diferentes verses de
aplicaes para diferentes dispositivos.
Os principais elementos (tags) SALT so:
" <prompt>, apresenta ao usurio gravaes de udio ou fala sintetizada;
" <listen>, reconhece palavras e frases ditas pelo usurio;
" <grammar>, especifica as palavras e frases que o usurio pode falar;
" <dtmf>, reconhece DTMF (teclas de telefone);
" <record>, captura fala e outros sons;
" <bind>, integra palavras e frases reconhecidas com a lgica da aplicao;
" <smex>, comunica-se com outros componentes da plataforma.
34
3.3.3 XFORMSMM
Outra linguagem para criao de interfaces multimodais apresentada por Honkala e
Pohja (2006). Os autores propem o XFormsMM, para autoria de aplicaes multimodal,
utilizando XForms como linguagem de descrio de interface com o usurio que permite o
uso de uma aplicao de vrias maneiras, focando no uso de interfaces grficas e de voz. A
utilizao do XFormsMM permite preencher e submeter qualquer formulrio escrito em
XForms, utilizando entradas de texto e voz simultaneamente.
O modelo separa as interfaces dependentes da modalidade (voz ou visual) das
interfaces independentes da modalidade, permitindo mudanas flexveis de modalidade e que
o usurio escolha que modalidade usar e quando usar.
A principal vantagem, segundo seus autores, que o XForms possui um conjunto
amplo de tipos de dados, maior acessibilidade devido ao alto nvel semntico de seus
elementos e pouca necessidade de se utilizar scripts, comuns nas tecnologias X+V e SALT.
3.3.4 EMMA
EMMA (Extensible MultiModal Annotation markup language) (BAGGIA et al.,
2007) uma linguagem de marcao usada para representar informao extrada da entrada
dos usurios que interagem com uma aplicao multimodal. Essa linguagem possibilita
atribuir significado para diferentes tipos de entrada como: texto, fala, escrita e combinaes
dessas entradas.
EMMA considera os seguintes tipos de entradas:
" Entrada por uma nica modalidade.
" Entradas por modalidades seqenciais.
" Entradas por modalidades simultneas, ou seja, a entrada pelas diferentes
modalidades interpretada uma aps a outra na ordem em que foram recebidas ao
invs de serem combinadas antes de ocorrer a interpretao.
" Entradas por modalidades compostas, ou seja, as entradas so recebidas ao mesmo
tempo por meio das mltiplas modalidades, e tratadas individualmente.
A linguagem EMMA est sendo utilizada primeiramente como um formato padro
para troca de dados entre sistemas multimodais e o objetivo que ela seja gerada
automaticamente por componentes de software (e no por desenvolvedores) responsveis
pela interpretao e usados para representar a semntica das entradas dos usurios.
35
A linguagem EMMA no representa uma linguagem de especificao e no contm
nenhuma abordagem transformacional para permitir desenvolvimento de aplicaes usando
diferentes modelos.
EMMA pode ser considerada uma linguagem complementar a SALT e X+V,
funcionando como uma camada intermediria entre os componentes da aplicao multimodal,
ou seja, entre a entrada do usurio e o interpretador SALT ou X+V. Isso permite que o
desenvolvedor no precise se preocupar em escrever cdigo para interpretar a entrada do
usurio, pois EMMA traduz a entrada em um formato interpretado pela linguagem de
desenvolvimento da aplicao multimodal, simplificando o processo de se adicionar vrias
modalidades a ela.
3.3.5 XHTML+VoiceXML (X+V)
O X+V (CROSS et al., 2003) um padro proposto pelo W3C para o
desenvolvimento de aplicaes com interface multimodal (visual e voz), que combina um
subconjunto de elementos XHTML, uma linguagem de marcao para criar aplicaes
visuais, e VXML. Ambas as linguagens so integradas por XML que disparam eventos DOM
(Document Object Model) para possibilitar a interao por voz.
DOM uma API proposta pelo W3C para estruturar documentos na Web em forma
de rvore. O objetivo do DOM permitir que os programadores acessem de maneira fcil os
elementos e atributos de documentos escritos em XML por meio de qualquer linguagem de
programao, utilizando as operaes conhecidas de manipulao de rvores.
As aplicaes criadas com o padro X+V podem conter estilos visuais fundamentados
em folhas de estilo e podem ser visualizadas por navegadores que contm um plugin para
reconhecimento de voz, como o Opera
1
, por exemplo.
Como pode ser observado na Figura 5, as aplicaes multimodais usando o padro
X+V permitem uma migrao natural das aplicaes de voz baseadas em VXML, geralmente
utilizadas em aplicaes para telefonia, e das aplicaes visuais em XHTML para uma
aplicao simples que pode ser executada em ambos os ambientes isoladamente e tambm em
conjunto.
As vantagens ao se usar X+V como linguagem de desenvolvimento so: a existncia
de uma comunidade de desenvolvedores altamente treinada em VXML, bem como materiais
de estudo, infra-estrutura e ferramentas disponveis dessa linguagem padronizada.
1
www.opera.com/
de voz alm dos com campos de dados tradicionais (
diante) e receba mensagens de voz bem como visuais. Este tipo simples de interao por voz
chamado um
DOCTYPE e a DTD da linguagem.
usados e contm
todas as funes de voz
funes de voz esto contidas
de voz correspondentes aos elementos que compem a
<body>, que contm todos os elementos grficos HTML. Adicionalmente, possui uma
referncia no formulrio que contm o elemento que trata os eventos para
<vxml:form>, responsvel por gerenciar a parte de voz
realizada independentemente da programao visual. Trechos de cdigo de VXML usados
nas aplicaes X+V podem ser reusados em aplicaes VXML.
Web, que o ambiente mais comum da interao, um padro
navegadores publicamente disponveis (tais como o Opera) suportam
que os desenvolvedores testem imediatamente
Figura
Uma aplicao
chamado uma interao dirigida por dilogo.
Os arquivos X+V so divididos em trs partes. O cabealho indica a verso XML, o
usados e contm os elementos
todas as funes de voz
A arquitetura modular do X+V permite que a programao do cdigo de voz seja
X+V a linguagem escolhida para es
, que o ambiente mais comum da interao, um padro
Figura 5 - Arquitetura para o desenvolvimento de aplicaes X+V.
Uma aplicao bsica de X+V permite que o usurio interaja por meio de comandos
a interao dirigida por dilogo.
os elementos
todas as funes de voz, e define o ttulo da pgina e indica que folha de estilo usar. As
Arquitetura para o desenvolvimento de aplicaes X+V.
bsica de X+V permite que o usurio interaja por meio de comandos
DOCTYPE e a DTD da linguagem. O elemento <html> aberto
os elementos <head> e <body>. A segunda part
define o ttulo da pgina e indica que folha de estilo usar. As
funes de voz esto contidas no elemento
Captulo 3
36
O elemento <html> aberto
<head> e <body>. A segunda part
no elemento <vxml:form>, que especifica todos os elementos
X+V a linguagem escolhida para este trabalho
que os desenvolvedores testem imediatamente as interfaces produzidas.
de voz alm dos com campos de dados tradicionais (checkboxes, input fields
O elemento <html> aberto
<head> e <body>. A segunda part
<vxml:form>, que especifica todos os elementos
de voz correspondentes aos elementos que compem a interface visual. A terceira parte o
<vxml:form>, responsvel por gerenciar a parte de voz.
te trabalho, porque
as interfaces produzidas.
Projeto de Interfaces Multimodais
checkboxes, input fields
O elemento <html> aberto para indicar os mdulos
<head> e <body>. A segunda parte o <head>, que inclui
interface visual. A terceira parte o
porque: suporta multimodalidade na
, que o ambiente mais comum da interao, um padro W3C
navegadores publicamente disponveis (tais como o Opera) suportam-na, permitindo, assim,
as interfaces produzidas.
checkboxes, input fields e assim por
para indicar os mdulos
e o <head>, que inclui
referncia no formulrio que contm o elemento que trata os eventos para o elemento
suporta multimodalidade na
W3C e atualmente
na, permitindo, assim,
e assim por
para indicar os mdulos
e o <head>, que inclui
o elemento
suporta multimodalidade na
e atualmente
na, permitindo, assim,
HTML com o objetivo de obter a quantidade de pizza desejada. No mesmo momento o
formulrio VXML representado pelo id=voice_quantity requisitado e um
emitido
responder por meio de fala ou digitando o nmero no campo de texto. Se ele optar pela fala, o
elemento <assign> copiar o nmero falado pelo usurio para o campo de texto de form
ele fique atualizado.
3.3.6
reconhecimento de voz sem restries, ou seja, no possvel para a aplicao converter a
fala para alguma outra representao, por exemplo, tra
Para se reconhecer uma entrada de voz necessria uma gramtica de regras. O JSGF (
Speech Grammar Format
independente de plataforma.
sero reconhecidas pela aplicao
No exemplo pode ser observada
gramtica identifica os seguintes
orange juice
como
Na Figura 6
Nesse exemplo, quando o arquivo carregado, foco colocado no campo de texto
emitido para o usurio perguntando:
JSGF
A tecnologia utilizada para reconhecer a fala em aplicaes X+V no suporta o
Speech Grammar Format
Na Figura 7
orange juice interpretado como
como food. Isso muito til quando
6 mostrado um exemplo de cdigo em X+V.
Figura
para o usurio perguntando:
Speech Grammar Format) um formato utilizado para representao de gramticas
7 apresentado um exemplo da forma
interpretado como
. Isso muito til quando
mostrado um exemplo de cdigo em X+V.
Figura 6 - Exemplo de cdigo em X+V.
para o usurio perguntando: How many pizzas would you like?
) um formato utilizado para representao de gramticas
Por meio dele possve
sero reconhecidas pela aplicao (GRUENSTEIN; MCGRAW; BADR, 2008)
apresentado um exemplo da forma
No exemplo pode ser observada uma gramtica identificada como
gramtica identifica os seguintes tokens:
interpretado como drink
. Isso muito til quando
Captulo 3
37
Exemplo de cdigo em X+V.
How many pizzas would you like?
dele possve
(GRUENSTEIN; MCGRAW; BADR, 2008)
apresentado um exemplo da forma
uma gramtica identificada como
: orange juice
drink e os tokens
. Isso muito til quando necessrio atribuir
fala para alguma outra representao, por exemplo, traduzir uma entrada de voz para texto.
dele possvel definir textualmente as palavras que
apresentado um exemplo da forma de um arquivo
orange juice, rice e
e os tokens rice
necessrio atribuir
duzir uma entrada de voz para texto.
l definir textualmente as palavras que
de um arquivo de gramtica
e steak,
rice e steak so interpretados
necessrio atribuir a mesma interpretao para
formulrio VXML representado pelo id=voice_quantity requisitado e um prompt
How many pizzas would you like?. O usurio pode
(GRUENSTEIN; MCGRAW; BADR, 2008).
de gramtica
uma gramtica identificada como food_drink
, sendo que o
steak so interpretados
a mesma interpretao para
prompt sonoro
. O usurio pode
elemento <assign> copiar o nmero falado pelo usurio para o campo de texto de forma que
Para se reconhecer uma entrada de voz necessria uma gramtica de regras. O JSGF (Java
de gramtica JSGF.
ink. Essa
endo que o token
so interpretados
a mesma interpretao para
diferentes entradas de voz. Por exemplo, quando espera
mas o usurio pode falar
uma aplicao VXML ou X+V, por exemplo
3.4
utilizados para as interfaces grficas tradicionais (GUI) no se aplicam necessariamente aos
sistemas multimodais, para os quais alguns tpicos importantes como o projeto das entradas e
sadas de informaes, d
ser considerados
maneiras
informaes bsicas sobre modelagem para usurios, o que os sistemas devem reconhecer e
como as arquiteturas multimodai
tecnologia de linguagem natural e do modo como as pessoas combinam o uso de diferentes
modos de entrada em uma interao.
propriedades inerentes aos diferentes modos, da informao que carregam e das
caractersticas de integrao e sincronizao.
multimod
o foco a percepo sensorial e capacidades de interao inerentes s diferentes modalidades
de entrada incorporadas em um sistema multimodal.
o usurio pode falar
A definio da gramtic
Abordagens para o projeto da interao multimodal
O projeto de interfaces multimoda
sadas de informaes, d
ser considerados (REEVES
Basicamente, o projeto de tais sistemas tem sido inspirado
maneiras (OVIATT, SHARON, 2003)
Primeiramente, seguindo as propostas encontradas na cincia cognitiva que fornece
A habilidade em se desenvolver sistemas multimodais depende do conhecimento da
O projeto de novos sistemas m
necessrio tambm considerar quando os usurios querem interagir de forma
multimodal e como so os padres de interao multimodal de diferentes usurios.
A literatura da cincia cognitiva bastante ampla nesse sentido especialmente quando
entrada incorporadas em um sistema multimodal.
o usurio pode falar yeah
Figura 7
definio da gramtic
sadas de informaes, da adaptabilidade, da consistncia e do tratamento de erros, alm de
REEVES et al.
(OVIATT, SHARON, 2003)
al e como so os padres de interao multimodal de diferentes usurios.
yeah, ok ou
7 - Exemplo de cdigo de gramtica JSGF
definio da gramtica reconhecedora
a adaptabilidade, da consistncia e do tratamento de erros, alm de
et al., 2004).
(OVIATT, SHARON, 2003).
como as arquiteturas multimodais devem ser organizadas.
Captulo 3
38
ou sure.
Exemplo de cdigo de gramtica JSGF
a reconhecedora de voz inseri
uma aplicao VXML ou X+V, por exemplo.
O projeto de interfaces multimodais importante porque os princpios e tcnicas
s devem ser organizadas.
O projeto de novos sistemas multimodais depende tambm do conhecimento das
diferentes entradas de voz. Por exemplo, quando espera-se que a entrada de voz seja
de voz inseri
importante porque os princpios e tcnicas
s devem ser organizadas.
ultimodais depende tambm do conhecimento das
que a entrada de voz seja
de voz inserida no formulrio de voz de
Basicamente, o projeto de tais sistemas tem sido inspirado e organizado de duas
que a entrada de voz seja
no formulrio de voz de
e organizado de duas
que a entrada de voz seja yes,
no formulrio de voz de
e organizado de duas
39
A segunda forma de organizao de um projeto multimodal so as simulaes
automticas e desenvolvimento de prottipos, que tambm vm desempenhando um papel
fundamental para auxiliar os desenvolvedores nos estgios iniciais de planejamento e
desenvolvimento de sistemas multimodais. Essas simulaes tm como objetivo visualizar o
sistema, suas funcionalidades e validar o fluxo da interao humano-computador, alm de
propiciar a obteno de dados com uma populao real e significativa de usurios.
A vantagem do uso de simulaes est no fato de que nelas as mudanas so fceis e
de baixo custo comparando-se com um sistema completo j construdo. Simulaes tambm
permitem que os pesquisadores alterem as caractersticas de um sistema planejado e estudem
o impacto de diferentes caractersticas de interfaces de uma maneira sistemtica, alm de
permitir tomada de decises sobre projetos alternativos.
Nesta reviso identificou-se a necessidade da pesquisa e criao de ferramentas para
apoiar o projeto, desenvolvimento e avaliaes de usabilidade de sistemas multimodais, e
vislumbra-se a seguinte infra-estrutura para o projeto de doutorado:
" ferramentas de simulao para construo e configurao rpida de interfaces
multimodais;
" ferramentas de automao para coleta e anlise de dados que melhorem a
usabilidade das interfaces;
" ferramentas de autoria para sistemas multimodais.
A seguir sero apresentadas as abordagens identificadas na literatura e que so usadas
para o projeto de interfaces multimodais Web atualmente.
3.4.1 Estado da arte das abordagens para projeto de interfaces
multimodais
O trabalho realizado por Stanciulescu et al. (2005) apresenta uma abordagem baseada
em transformaes para o desenvolvimento de interfaces multimodais para Web. Em tal
abordagem utilizado um framework de referncia, o Cameleon (LIMBOURG et al., 2005),
que decompe o ciclo de vida de uma interface em quatro nveis: modelo de tarefas, modelo
de domnio, interface abstrata e interface concreta. Cada um deles realizando transformaes
do passo anterior para o seguinte at a obteno da interface multimodal final.
Os passos para a obteno da interface multimodal so: obter uma ou vrias interfaces
abstratas de um modelo da tarefa e de um modelo do domnio, derivando uma ou vrias
interfaces concretas de cada interface abstrata, e produzir o cdigo das interfaces finais
correspondentes.
40
Todos os elementos, modelos e transformaes entre os nveis so especificados
uniformemente por meio de uma nica linguagem de descrio de interface, a UsiXML (User
Interface eXtensible Markup Language) (LIMBOURG et al., 2005), que permite aplicar
regras de transformaes no modelo de entrada e produzir o modelo grfico de sada
resultante. Dessa forma, todo o conhecimento de projeto necessrio para conduzir as
transformaes est explicitamente contido nas regras de transformaes e a execuo dessas
regras garantida por um mecanismo de transformao que est separado da lgica de
transformao, possibilitando que o projetista explore muitas alternativas e obtenha diversos
tipos de interfaces sem precisar reiniciar o processo.
Todas as interfaces resultantes so consistentes entre si, pois o mecanismo de
transformao tem como base o mesmo modelo de tarefas e de domnio. A interface final
multimodal e atualmente envolve interao grfica convencional (teclado e mouse) e
interao por voz, podendo ser estendida no futuro.
Fabio Patern e seu grupo de pesquisa fundamentam seus trabalhos no problema de
que desenvolver interfaces multimodais ainda uma tarefa difcil para os projetistas e
desenvolvedores e h falta de ferramentas de autoria para esta finalidade, especialmente
quando so considerados os ambientes multi-dispositivos, como: desktop grfico, desktop
com suporte de voz e celular. Em (PATERNO; GIAMMARINO, 2006) os autores
apresentam uma mtodo e um instrumento de apoio para auxiliar no desenvolvimento de
vrias verses de interfaces e vrias maneiras para combinar grficos e voz em ambientes
multi-dispositivos que podem se adaptar aos recursos de interao disponveis e evitar
confundir o projetista com muitos detalhes relacionados aos dispositivos e linguagens de
programao.
A idia ter algumas descries lgicas prximas da viso do usurio e ambientes
inteligentes capazes de transformar interfaces a fim de obter adaptaes para os dispositivos
alvos.
Esse grupo de pesquisa trabalha com um mtodo que deriva interfaces multimodais a
partir das descries lgicas das tarefas e das interfaces do usurio obtidas por meio das
notaes gerais, independentes de plataforma. H ainda a possibilidade de combinar as
modalidades de vrias maneiras, mas em nveis diferentes de granularidade (dentro de um
nico objeto de interao e entre diversos objetos de interao).
Uma descrio lgica (PATERNO, 1999) composta por:
41
" Nveis de tarefa e de objeto, que refletem a viso do usurio sobre o sistema
interativo em termos das atividades lgicas e dos objetos que devem ser
manipulados para realiz-las.
" Interfaces abstratas, que fornecem uma descrio independente da modalidade
da interface com o usurio (por exemplo, uma interao por gesto ou um comando
de voz ou uma interao grfica).
" Interfaces concretas, que fornecem uma descrio dependente da modalidade e
uma descrio independente da linguagem de implementao da interface (por
exemplo, seleo pode ser feita por radio-button ou uma lista ou um menu drop-
down). O nvel concreto um refinamento da interface abstrata dependendo da
plataforma associada.
" Implementao final, em uma linguagem de implementao de interface.
Existe tambm uma ferramenta chamada Teresa que funciona em um ambiente
fundamentado em transformaes de interfaces multimodais para diversos dispositivos
utilizando a TeresaXML (MORI; PATERNO; SANTORO, 2004) e utilizando a descrio
lgica descrita anteriormente.
Os autores comparam o mtodo proposto ao mtodo do trabalho de Stanciulescu
(2005), que aplica transformaes s descries lgicas para derivar interfaces multimodais.
Segundo os autores, a diferena que o trabalho atual pde fornecer um ambiente de autoria
que pode sugerir solues para identificar como combinar vrias modalidades e permite que
os desenvolvedores as modifiquem facilmente a fim de adequar a gerao da interface s suas
necessidades especficas.
A vantagem deste tipo de abordagem que permite que os desenvolvedores focalizem
em aspectos lgicos e considerem a viso do usurio nos estgios mais iniciais do processo
do projeto. No caso das interfaces que podem ser alcanadas atravs dos tipos diferentes de
dispositivos a abordagem tem vantagens adicionais, pois a tarefa e o nvel abstrato podem ser
descritos com a mesma linguagem para qualquer plataforma de destino. Portanto, h uma
linguagem de interface concreta para cada plataforma destino.
Existem tambm outras propostas baseadas em XML, mas que no consideram
explicitamente multimodalidade como, XIML (PUERTA; EISENSTEIN, 2002) e UIML
(ABRAMS et al., 1999).
O projeto MONA (Mobile multimOdal Next generation Applications) (ANEGG et al.,
2004) fornece um ambiente para se desenvolver aplicaes multimodais Web. Tal ambiente
42
composto por um servidor de apresentao, que permite o desenvolvimento de aplicaes
mveis flexveis, disponvel para um grande nmero de dispositivos mveis. Esse servidor de
apresentao transforma uma especificao de interface multimodal em uma combinao de
interface grfica e de voz e a adapta dinamicamente para diversos tipos de dispositivos: WAP
Phones, Smart Phones, PocketPC e PDAs. O mtodo de desenvolvimento da aplicao
multimodal fundamentado em casos de uso, que permitem o refinamento e a validao do
projeto por meio de prottipos de interface para cada tipo de dispositivo. Os idealizadores do
projeto MONA recomendam que esses prottipos gerados sejam submetidos a avaliaes
heursticas executadas por avaliadores experientes.
Na reviso bibliogrfica percebeu-se que esses mtodos no consideram princpios,
guidelines ou padres de projeto para facilitar o projeto de interfaces multimodais Web. Tais
conceitos so fundamentais, pois orientam os projetistas na tomada de decises consistentes
atravs dos elementos que constituem o produto e so tcnicas eficientes para capturar,
documentar e comunicar o conhecimento adquirido, aplicado e validado cientificamente em
determinadas circunstncias.
A seguir sero apresentados os frameworks identificados na literatura e que so
usados para o projeto de interfaces multimodais Web.
3.4.2 Frameworksconceituais para desenvolvimento de sistemas
multimodais Web
Durante a pesquisa bibliogrfica sobre o estado da arte para projetos de sistemas
multimodais foram encontrados frameworks para apoiar o desenvolvimento de tais sistemas.
Os dois principais frameworks usados pela comunidade de projetistas de sistemas
multimodais so apresentados a seguir.
3.4.2.1 Framework ICARE (Interao, Complementaridade, Associao, Redundncia e
Equivalncia).
As propriedades CARE (Complementaridade, Associao, Redundncia e
Equivalncia) representam uma forma de caracterizar as relaes que podem ocorrer entre
diferentes modalidades de interao disponveis nas interfaces multimodais. Como
apresentado no primeiro Captulo, uma modalidade descrita como uma relao entre um
dispositivo fsico e uma linguagem de interao. Coutaz e seus colegas em (COUTAZ et al.,
1995) propuseram termos para definir objetivamente as propriedades CARE:
" Estado: um conjunto de propriedades que podem ser medidas em um
determinado momento para caracterizar uma situao.
43
" Objetivo: um estado passvel de ser alcanado por um agente.
" Agente: uma entidade capaz de executar aes.
" Modalidade: um mtodo de interao que um agente pode usar para atingir um
objetivo.
" Relaes Temporais: caracterizam o uso das modalidades que podem ocorrer
simultaneamente ou em seqncia em um intervalo de tempo.
As propriedades CARE foram definidas baseadas nas noes mostradas anteriormente
e so descritas a seguir:
Complementaridade: duas ou mais modalidades devem ser usadas de forma
complementar para se atingir um determinado estado. caracterizada por um modo
dominante que requer o uso de outros modos. Por exemplo, considere a situao na qual uma
interface multimodal tem um campo de texto no preenchido que permite ao usurio fornecer
seu nome como entrada (Estado inicial). Este campo de texto deve ser preenchido (Estado
final) por um agente que fornece entrada por fala usando microfone e linguagem natural com
vocabulrio restrito para falar a primeira parte de seu nome e entrada grfica usando mouse e
manipulao direta para completar a tarefa.
Associao: expressa a atribuio de uma modalidade especfica em um determinado
estado de origem para se atingir um estado destino. Expressa a ausncia de escolha de um
outro modo. Por exemplo, considere a situao na qual uma interface multimodal tem um
campo de texto que no est preenchido (Estado inicial). Este campo de texto deve ser
preenchido (Estado final) por um agente que pode utilizar uma nica modalidade para isso,
entrada por linguagem natural escrita utilizando teclado.
Redundncia: expressa a utilizao de duas ou mais modalidades ao mesmo tempo
para se atingir um estado destino. Por exemplo, considere a situao na qual uma interface
multimodal tem uma caixa de seleo que pode ser selecionada por um agente usando duas
modalidades, entrada por fala usando microfone e linguagem natural com vocabulrio restrito
e entrada grfica usando mouse e manipulao direta, em paralelo ou seqencialmente, mas
no mesmo intervalo de tempo.
Equivalncia: expressa a disponibilidade de escolha entre mltiplas modalidades,
mas no impe nenhuma restrio temporal. Por exemplo, considere a situao na qual uma
interface multimodal tem um campo de texto que no est preenchido (Estado inicial). Este
campo de texto deve ser preenchido (Estado final) por um agente que pode utilizar duas
modalidades para isso, entrada por fala usando microfone e linguagem natural com
vocabulrio restrito e linguagem natural escrita utilizando teclado.
CARE), uma abordagem baseada em componentes que permite projeto e desenvolvimento
rpidos de interfaces multimodais. Existem dois tipos de componentes, os bsicos, que
descrevem uma modalidade simples (dispositivo em conjunto com lingua
os componentes compostos, que descrevem o uso combinado de modalidades (propriedades
CARE). A plataforma permite ao projetista manipular graficamente os componentes para
especificar uma interao multimodal, alm de gerar o cdigo da in
3.4.2.2
identificar os componentes bsicos dos sistemas multimodais, as linguagens de marcao
definidas pelo W3C e util
o fluxo de dados entre esses componentes.
ser estendido para incluir novos modos.
Figura
Multimodal do W3C:
Bouchet, Nigay e Ganille
Framework
A proposta do
definidas pelo W3C e util
O framework
Figura 8 - Componentes bsicos do
Na Figura
Multimodal do W3C:
" Usurio
informao de sada apresentada pelo sistema.
" Componente de Entrada de Informao
como udio, fala, escrita, teclado. A linguagem de marcao EMMA pode ser
usada para identificar a semntica dos dados que representam a en
usurio.
Nigay e Ganille
Framework para interao
A proposta do Framework
definidas pelo W3C e utilizadas para descrever a informao requerida pelos componentes e
framework descreve os modos de entrada e sada mais utilizados atualmente e pode
Componentes bsicos do
8 so ilustra
Multimodal do W3C:
Usurio: fornece entrada de informao para o sistema, observa e ouve a
ormao de sada apresentada pelo sistema.
Componente de Entrada de Informao
usurio.
Nigay e Ganille (2004
nterao multimodal do W3C
Framework para Interao Multimodal do W3C
izadas para descrever a informao requerida pelos componentes e
descreve os modos de entrada e sada mais utilizados atualmente e pode
Componentes bsicos do Framework
(LARSON, 2003)
ilustrados os componentes bsicos do
: fornece entrada de informao para o sistema, observa e ouve a
Captulo 3
44
2004) propuseram o
ultimodal do W3C
ra Interao Multimodal do W3C
Framework
(LARSON, 2003)
os componentes bsicos do
propuseram o framework
ultimodal do W3C
ra Interao Multimodal do W3C
Framework para Interao Multimodal do W3C
(LARSON, 2003)
os componentes bsicos do
Componente de Entrada de Informao: contm vrias modalidades de entrada
framework ICARE (Interaction
descrevem uma modalidade simples (dispositivo em conjunto com linguagem de interao) e
especificar uma interao multimodal, alm de gerar o cdigo da interface automaticamente.
ra Interao Multimodal do W3C (LARSON, 2003)
para Interao Multimodal do W3C
os componentes bsicos do Framework
: contm vrias modalidades de entrada
ICARE (Interaction
gem de interao) e
terface automaticamente.
(LARSON, 2003)
Framework para Interao
usada para identificar a semntica dos dados que representam a entrada do
ICARE (Interaction
gem de interao) e
terface automaticamente.
(LARSON, 2003),
para Interao
trada do
45
" Componentes de Sada Informao: considera as vrias mdias de sada como
voz, texto, grfico, arquivos de udio e animao. O componente de sada pode
ser projetado nas seguintes linguagens: SSML (Speech Synthesis Markup
Language) usada para descrever como as palavras devem ser pronunciadas,
XHTML ou SVG usado para descrever como os grficos devem ser tratados e
SMIL que pode ser usado para coordenar sada multimdia.
" Gerenciador da Interao: o componente lgico que coordena os dados e
gerencia o fluxo de execuo das vrias modalidades de entrada e sada. Ele
mantm o estado da interao, o contexto da aplicao e responde s entradas dos
objetos de interface e s mudanas no sistema e no ambiente.
" Componente de Sesso: fornece uma interface para o gerenciador da interao
para apoiar o gerenciamento dos estados e sesses temporrias e persistentes para
aplicaes multimodais.
" Componentes de Sistema e Ambiente: permite que o gerenciador da interao
procure e responda s alteraes nos dispositivos, preferncias do usurio e
condies do ambiente, por exemplo, qual dos modos disponveis o usurio deseja
utilizar, a resoluo do vdeo, se suporta cor ou no.
Os requisitos para a especificao da interao multimodal e gerenciamento da
entrada de informaes esto descritos em (MAES; SARASWAT, 2003). De acordo com o
Framework para Interao Multimodal do W3C, existem trs nveis para o gerenciamento da
interao:
" Entrada multimodal sequencial: aquela que fornecida com o uso de uma
nica modalidade em um espao de tempo. possvel especificar qual modalidade
ou dispositivo usar para fornecer a entrada alm de fornecer dicas para troca de
modalidade em um determinado momento da interao.
" Entrada multimodal simultnea: as entradas utilizando diferentes modalidades
so interpretadas uma aps a outra de acordo com a ordem de ocorrncia.
" Entrada multimodal composta: a entrada recebida com o uso de vrias
modalidades ao mesmo tempo e interpretada em conjunto.
Como pode-se perceber existe uma semelhana entre esses nveis de gerenciamento e
as propriedades CARE apresentadas anteriormente.
A diferena entre os frameworks a forma como eles definem e consideram a noo
de modalidade. Enquanto uma modalidade, para as propriedades CARE, descrita como uma
46
relao entre um dispositivo fsico e uma linguagem de interao, para o W3C Multimodal
Interaction Framework uma modalidade um tipo de canal de comunicao usado para a
interao e considera a forma como uma idia expressa ou percebida, ou ainda a maneira
como uma ao executada.
Existem algumas semelhanas entre as propriedades CARE e os requisitos
especificados no W3C Multimodal Interaction. A propriedade Redundncia poderia ser
expressa usando as modalidades seqencialmente ou em paralelo, que corresponde
respectivamente aos requisitos de entrada multimodal seqencial e simultneo identificados
pelo W3C Multimodal Interaction Working Group.
Da mesma forma, a propriedade Complementaridade prev o uso individual de
modalidades em seqncia ou em paralelo e que corresponde aos requisitos seqencial e
composto do W3C, respectivamente.
Neste captulo foi apresentada uma ampla viso de como o projeto de um sistema
multimodal pode ser organizado, as tecnologias, as abordagens, os mtodos e os frameworks
existentes para viabilizar o desenvolvimento de tais sistemas.
Percebe-se que as novas linguagens de marcao como o X+V, o SALT e o EMMA
possibilitam o desenvolvimento de interfaces Web e aplicaes multimodais de forma
semelhante ao desenvolvimento Web tradicional e os frameworks apresentados apiam o
desenvolvimento organizado de tais sistemas.
Esses dados pesquisados foram utilizados durante o desenvolvimento do projeto de
doutorado, com o objetivo de servir como uma lista de requisitos e as correspondentes
motivaes para o projeto e desenvolvimento de interfaces multimodais Web.
No Captulo 4 ser apresentada a abordagem que ser utilizada para a continuao
desta pesquisa e no Captulo 5 ser apresentado o ambiente de autoria que foi criado para
facilitar as atividades de projeto de interfaces multimodais Web.
Captulo 4 - Abordagem para o Desenvolvimento de Interfaces Multimodais Web (MMWA)
47
Captulo 4. Abordagem para o
Desenvolvimento de Interfaces
Multimodais Web (MMWA)
Neste captulo apresentada a abordagem para o projeto, desenvolvimento e
avaliao de usabilidade de interfaces multimodais Web proposta nesta tese, bem como os
seus objetivos, sua estrutura e a descrio de suas atividades. A abordagem definida na
Seo 4.2 e suas cinco atividades so detalhadas entre as Sees 4.3 e 4.7. Na Seo 4.8
apresenta-se as consideraes sobre o uso de design rationale (DR) na abordagem proposta.
No final do captulo, na Seo 4.9, feita uma breve comparao com as abordagens,
linguagens e frameworks existentes na literatura e as consideraes finais so apresentadas na
Seo 4.10.
4.2 Definio da MMWA
A abordagem para o desenvolvimento de interfaces multimodais Web (MultiModal
Web Approach - MMWA) foi criada com objetivo de propiciar equipe de projetistas,
desenvolvedores e testadores de interfaces multimodais uma estrutura prtica composta por
atividades e tcnicas para serem utilizadas em suas tarefas cotidianas de forma otimizada, ou
seja, reusando artefatos e conhecimento de projetos anteriores de forma a maximizar a
comunicao entre a equipe.
A abordagem segue um modelo em espiral, centrado no usurio, representado na
Figura 9, composto por cinco atividades (MCI, IT, RT, AS e AU) e um conjunto de tcnicas
que sero descritas neste captulo. Esse ferramental permite armazenar, capturar e utilizar DR
em todas as atividades com o objetivo de prover solues de sucesso para problemas
recorrentes no contexto da interao multimodal por meio de registro de discusso de
decises, justificativas, alternativas e argumentos que culminam com a documentao e o
projeto final para reutilizao futura.
A MMWA promove a reutilizao sistemtica de software de forma controlvel,
gerencivel e repetvel (ROMBACH, 2000) durante as fases de projeto e desenvolvimento,
pois tanto os artefatos gerados em projetos anteriores quanto o conhecimento capturado na
Captulo 4
forma de DR so reaproveitados, em contraste com uma abordagem
da criatividade e do conhecime
de um mesmo contexto bem definido, utiliza
projeto
identificao de padres de projeto que ser apresentada mais adiante no
Destaca
problemas que ocorrem quando reutiliza
de DR.
Figura
Identificao de Tarefas
conhecimento e o raciocnio inerente ao processo de projeto. Nos estudos de caso realizados,
o DR foi documentado como discusses entre os participantes envolvidos no projeto usando
Captulo 4 - Abordagem para o Desenvolvimento de Interfa
Para promover
(GAMMA
Destaca-se que a reutilizao realizada em nvel de modelo de tarefas, evitando os
Figura 9 - As atividades da MMWA: 1
Identificao de Tarefas
O DR utilizado no contexto da MMWA, metodologicamente,
Abordagem para o Desenvolvimento de Interfa
promover essa reutilizao, aproveitando a similaridade entre aplicaes dentro
(GAMMA et al., 1995)
se que a reutilizao realizada em nvel de modelo de tarefas, evitando os
As atividades da MMWA: 1
Identificao de Tarefas (IT
(AS); 5
da criatividade e do conhecimento individual dos projetistas.
essa reutilizao, aproveitando a similaridade entre aplicaes dentro
, 1995). Neste trabalho
problemas que ocorrem quando reutiliza-
As atividades da MMWA: 1
T); 3- Representao de Tarefas
(AS); 5-Avaliao de Usabilidade
48
nto individual dos projetistas.
de um mesmo contexto bem definido, utiliza-se a tcnica de
. Neste trabalho, tam
-se somente o cdigo fonte, por exemplo
As atividades da MMWA: 1-Modelo Comportamental Inicial
Representao de Tarefas
Avaliao de Usabilidade
Abordagem para o Desenvolvimento de Interfaces Multimodais
nto individual dos projetistas.
se a tcnica de DR
tambm generaliza
e o cdigo fonte, por exemplo
Modelo Comportamental Inicial
Representao de Tarefas (R
Avaliao de Usabilidade (AU
ces Multimodais
forma de DR so reaproveitados, em contraste com uma abordagem ad hoc
DR e o conceito de padres de
bm generaliza-se uma tcnica para a
e o cdigo fonte, por exemplo
Modelo Comportamental Inicial
RT); 4- Anlise das Solues
AU).
ces Multimodais Web (MMWA)
ad hoc, que dependente
o conceito de padres de
se uma tcnica para a
identificao de padres de projeto que ser apresentada mais adiante no Captulo 7
e o cdigo fonte, por exemplo, a extrao
Modelo Comportamental Inicial (MCI); 2
Anlise das Solues
O DR utilizado no contexto da MMWA, metodologicamente, visa reter
(MMWA)
, que dependente
o conceito de padres de
se uma tcnica para a
Captulo 7.
a extrao
); 2-
Anlise das Solues
visa reter o
49
uma ferramenta de colaborao, um sistema de Wiki que foi configurado para gerar pginas
com a estrutura necessria para o registro de DR. Essa particularidade permite a edio
colaborativa de decises de projeto e projeto participativo de forma coletiva, bem como
controlar o histrico de edio, contar os acessos ao DR e facilitar o controle de verses.
Uma fase elementar no desenvolvimento de interfaces multimodais envolve a
avaliao de prottipos fundamentando-se em estudos qualitativos e interaes com usurios
reais, descritos previamente nesta tese no Captulo 2 e no Captulo 3.
Uma das principais caractersticas da MMWA o mecanismo de avaliao de
usabilidade baseado na Web que foi projetado para permitir a obteno de dados para a
identificao, anlise e correo de problemas, em estgios iniciais do projeto.
O benefcio de se realizar estudos de usabilidade remotos usando a Web que os
usurios podem ser recrutados em qualquer lugar do mundo e podem interagir quando for
mais conveniente, deixando-os mais vontade para realizar as tarefas no local onde
frequentemente realizam a interao, ou seja, sem a necessidade de expor o usurio a uma
sala de monitorao que no o seu ambiente corriqueiro de utilizao de sistemas dessa
natureza.
Um tpico adicional considerado pela MMWA, e que muito abordado em artigos
cientficos na rea em questo, a fuso e a fisso das modalidades, que podem ser
combinadas de quatro diferente maneiras, expressas pelas propriedades CARE (COUTAZ et
al., 1995). Consequentemente essas propriedades so tambm usadas para estruturar e apoiar
a atividade de avaliao de usabilidade.
Em resumo, os objetivos com a proposta da MMWA so:
" Permitir o projeto de interfaces multimodais Web fundamentando-se em teorias de
comprovada eficincia, compilando os pontos positivos de cada tcnica utilizada.
" Implementar as interfaces de forma rpida e considerar os conceitos relacionados
a multimodalidade tais como gramticas e prompts de voz, sincronizao de
interfaces, gerenciamento de eventos e tratamento de mensagens e erros.
" Testar e validar as interfaces projetadas e desenvolvidas em busca de padres de
interao e problemas de usabilidade.
50
" Reusar o conhecimento capturado e armazenado previamente em projetos
subsequentes utilizando DR
Nas sees seguintes sero descritas as cinco atividades da MMWA e as tcnicas
utilizadas em cada atividade.
4.3 Modelo Comportamental Inicial (MCI)
Rousseau et.al. (2005) recomendam que a primeira atividade a se fazer durante um
projeto de uma nova interface criar um corpo de dados consistindo de cenrios e situaes
nas quais a interface ser utilizada e tambm de informaes sobre o ambiente em que a
aplicao ser executada.
Portanto, a primeira atividade da MMWA o desenvolvimento de um modelo
comportamental inicial, Figura 10, que consiste na definio de cenrios, identificao de
restries, informaes sobre o ambiente em que as tarefas multimodais sero executadas,
tais como o pblico alvo e suas caractersticas e informaes sobre experincia do usurio
que devem ser consideradas no projeto e desenvolvimento das interfaces. Esses dados
formam os elementos necessrios para construir as partes essenciais do sistema. Tanto o
projetista como os usurios devem estar envolvidos nesse trabalho inicial.
O objetivo identificar a informao que ser trocada entre o usurio e o sistema
durante a execuo da tarefa multimodal no artefato que ser projetado (a interface). Para
tanto, necessrio obter a informao do domnio para que se possa selecionar e projetar o
mapeamento de tarefas apropriadas e a sua representao na forma de uma interface
multimodal.
Toda a informao obtida com a execuo dessa atividade documentada como a
especificao de requisitos da aplicao multimodal, que ajuda estabelecer as medidas de
usabilidade que sero utilizadas nos testes para garantir que o software atenda a expectativa
do cliente, bem como priorizar requisitos de acordo com um critrio acordado com o cliente,
incluir informaes de contrato e aspectos legais, referncias a padres relevantes e
documentos/requisitos internos do cliente. A atividade MCI esquematizada na Figura 10.
51
Figura 10 MMWA: Modelo Comportamental Inicial
Toda a informao necessria para a especificao de requisitos na atividade de
obteno do modelo comportamental inicial da aplicao multimodal pode ser obtida com o
uso das seguintes tcnicas de acordo com as caractersticas do projeto:
" Em estudos de campo, utilizando Entrevistas e Questionrios e Business Use
Case.
" Com a participao direta de usurios em Focus Groups.
" Participao do cliente em Cenrios de Uso e Reunio para coleta de Requisitos.
Entrevistas e Questionrios, ou pesquisas, so um meio de descobrir como o software
tende a ser utilizado por um conjunto especfico de usurios. As respostas que os usurios
fornecem devem ser relevantes para as questes que so importantes para a equipe de projeto.
Pesquisas com usurios so tradicionalmente realizadas presencialmente, mas cada vez mais,
a Internet utilizada para esta finalidade. As pesquisas apenas so benficas se geram
respostas s perguntas da equipe de projeto. Pelo fato de ser possvel fazer uma pesquisa com
um grande nmero de usurios, perfis de uso podem ser obtidos se a metodologia correta for
utilizada. Pesquisas so frequentemente analisadas estatisticamente, no entanto, dados
qualitativos podem ser obtidos com esta tcnica.
O Business Use Case ou Caso de Uso de Negcio empregado para fornecer o
contexto no qual o negcio da empresa opera. Ele representa os atores, como os clientes, as
partes interessadas, as empresas, bem como as funes de negcio (casos de uso) e as
relaes entre eles. usado como uma ferramenta essencial para identificar papis e produtos
52
da organizao. O Business Use Case pode ser utilizado como uma alternativa ou como uma
representao grfica para a modelagem de cenrios. No entanto a utilizao da especificao
de casos de uso UML (BOOCH; RUMBAUGH; JACOBSON, 2005) tem recebido algumas
crticas. Patern (1999) afirma que difcil identificar casos de uso para sistemas complexos
e definir o nvel de granularidade adequado. Esse problema pode ser solucionado com a
aplicao da anlise de tarefas, como ser apresentado na prxima seo, pois esta tcnica
permite que se obtenha uma viso ampla dos nveis abstrato e concreto das interfaces em um
sistema complexo.
Focus Groups uma tcnica utilizada como pesquisa qualitativa, geralmente uma
reunio informal de usurios para que suas opinies sobre um determinado assunto sejam
ouvidas por um moderador experiente, que responsvel por manter o foco do grupo sobre as
questes de interesse para os resultados (KRUEGER; CASEY, 2000). O objetivo obter as
percepes do usurio sobre a usabilidade de uma interface antes que ela seja construda e
no uma tcnica eficiente para avaliaes de usabilidade (NIELSEN, 1997). Os resultados
no geram informaes quantitativas e no devem ser generalizados, mas podem ser
utilizados como base para a gerao de hipteses para posterior avaliao e validao
utilizando mtodos qualitativos e quantitativos.
Cenrios de Uso so histrias escritas sobre usurios e suas atividades no sistema e
so utilizados para fornecer uma viso abstrata do sistema e ajudar na elucidao de
requisitos (CARROL, 1999). necessrio definir um estado inicial, uma configurao e um
ator para realizar as tarefas no cenrio. O fluxo do cenrio define o conjunto de tarefas que o
usurio executa no sistema, bem como os eventos que acontecem durante a interao.
Reunio para coleta de Requisitos uma reunio ou evento realizado com
desenvolvedores, projetistas e clientes para identificar requisitos da aplicao que sero teis
na fase de desenvolvimento e testes. Esta tcnica visa considerar a usabilidade em estgios
iniciais do projeto, bem como, identificar os requisitos e quesitos de usabilidade que sero
usados para avaliar as interfaces e como os requisitos eficcia, eficincia e satisfao sero
medidos.
Alm dessas tcnicas, o modelo em camadas para obteno de requisitos apresentado
na Seo 2.4 deve ser utilizado para ajudar a compreender os diferentes conceitos durante a
fase de anlise de requisitos.
53
4.4 Identificao das Tarefas (IT)
A fase de projeto tem incio com a segunda atividade da MMWA, que consiste em
identificar as tarefas que sero executadas pelos usurios na interface multimodal (Figura 11).
Esse passo fornece uma viso geral de como a interao ser executada sobre o ponto de vista
do usurio final.
Uma tarefa na MMWA composta por um nome, um tipo e uma representao. O
nome definido nesta atividade e composto por uma combinao de verbo e substantivo,
por exemplo, SelecionarCarto. O verbo descreve o tipo de ao que ser executada e o
substantivo descreve o objeto alvo da ao. A representao final obtida na prxima
atividade e permite obter o Modelo de Tarefas.
O objetivo com a execuo desta atividade analisar aspectos importantes das tarefas
como: objetivos, estados iniciais e finais, atividades e procedimentos envolvidos, identificar
os problemas que podem ocorrer, identificar se existem restries para a execuo da tarefa
no ambiente em que ela ser executada, avaliar as informaes obtidas na atividade anterior
sobre o pblico alvo e sua experincia e planejar a entrada e sada multimodal.
Figura 11 - MMWA: Identificao de Tarefas
Algumas tcnicas auxiliam na identificao e na representao das tarefas, tais como
o Diagrama de Estados e o Diagrama de Atividades da UML (BOOCH; RUMBAUGH;
JACOBSON, 2005).
Na Figura 12 ilustrado um diagrama de estados e transies para as tarefas que
foram identificadas no segundo estudo de caso, que ser apresentado no Captulo 6, um
sistema multimodal para encontrar a rota entre dois pontos de interesse em um mapa. Os
estados representam as seguintes tarefas: T1:ChooseOrigin (escolher local de partida); T2:
ChooseDestination (escolher local de chegada); T3: ConfirmPlaces (confirmar pontos de
interesse), T4: HearStepCommands (apresentar o caminho entre os pontos escolhidos). As
Captulo 4
transies indicam os eventos
uma nova tarefa como apresentado n
UML, que tipicamente usado
lgica de um caso de uso ou de um cenrio, ou para modelar a lgica detalhada de uma regra
de negcio.
aplicao multimodal de rotas entre dois pontos de interesse em um mapa, desenvolvida no
segundo
4.5
abstratas e concretas para as tarefas previamente identificadas. Representaes abstratas so
os tipos de tarefas. Na MMWA so possveis os seguintes tipos: Seleo, Navegao
(transies), Deci
Figura 12
Nos estudos de caso
de negcio. No exemplo da
segundo estudo de caso
Figura
Representa
Na terceira atividade
(transies), Deciso, Agrupamento, Controle, Entrada e Sada.
Exemplos:
" Seleo
" Navegao
de pagamento de contas
" Deciso
" Agrupamento
12 - Diagrama de
Nos estudos de caso realiz
No exemplo da
estudo de caso.
Figura 13 - Diagrama de atividades utilizado no estudo de caso 2
Representao de
Na terceira atividade, que
so, Agrupamento, Controle, Entrada e Sada.
Seleo de um tipo de carro em um sistema de locadora
Navegao (transio)
de pagamento de contas
Deciso baseada em uma lgica de negcio
Agrupamento de Selees no caso de uma data: dia, ms e ano
transies indicam os eventos que ocorrem para a ativao de um outro estado e o incio de
uma nova tarefa como apresentado no Quadro
Diagrama de transio de
realizados tambm foi utilizado o Di
UML, que tipicamente usado para a modelagem de pr
Figura 13
Diagrama de atividades utilizado no estudo de caso 2
Tarefas (
, que representada na
de um tipo de carro em um sistema de locadora
(transio) entre a interface principal de um sistema e uma interface
de pagamento de contas.
baseada em uma lgica de negcio
de Selees no caso de uma data: dia, ms e ano
54
que ocorrem para a ativao de um outro estado e o incio de
Quadro 3.
transio de estados utilizado no
ados tambm foi utilizado o Di
para a modelagem de pr
13, apresentado o Diagrama de
(RT)
representada na Figura
entre a interface principal de um sistema e uma interface
baseada em uma lgica de negcio
estados utilizado no
ados tambm foi utilizado o Di
para a modelagem de processos de negcio, para captura
, apresentado o Diagrama de
Figura 14, o projetista cria representaes
baseada em uma lgica de negcio.
ces Multimodais
estados utilizado no estudo de caso 2
ados tambm foi utilizado o Diagrama de
ocessos de negcio, para captura
, apresentado o Diagrama de
o projetista cria representaes
de um tipo de carro em um sistema de locadora.
estudo de caso 2
ama de Atividades da
ocessos de negcio, para captura
Atividades para a
de Selees no caso de uma data: dia, ms e ano.
(MMWA)
Atividades da
ocessos de negcio, para capturar a
Atividades para a
55
" Controle da Navegao, por exemplo, submeter ou limpar os dados de um
formulrio, voltar para o menu principal, solicitar auxlio ou pedir para repetir
uma informao.
" Entrada de dados, como um nome.
" Sada de dados, como ouvir os itens selecionados.
Tcnicas como as descritas em (PATERNO, 1999) ou (STANCIULESCU et al.,
2005), que realizam transformaes nos nveis concretos e abstratos das interfaces at obter a
interface multimodal final podem ser aplicadas para este propsito e tambm com o objetivo
de transformar as interfaces para dispositivos diferentes dos convencionais.
Os elementos necessrios para gerar e analisar qualquer tipo de entrada ou sada
multimodal incluindo os seus prs e contras so documentados na forma de DR. Como
resultado, uma lista de elementos de interface candidatos para cada modalidade ou
combinao de modalidades obtida. O objetivo produzir uma srie de discusses entre os
projetistas com as solues e argumentos, e comparar as vantagens e desvantagens do DR
obtido.
Figura 14 - MMWA: Representao de Tarefas
Aps a identificao das representaes abstratas das tarefas possvel definir a
apresentao, ou seja, os elementos de interface grfica (botes, menus, disposio dos
elementos, etc) e de voz (prompts, gramticas, comportamentos de erro, etc) e o
comportamento, ou seja, os mtodos e funes necessrios para habilitar ou disparar as
transies, bem como os eventos que sero ativados em cada elemento da interface.
Esse passo chamado de representao concreta, pois depende da tecnologia
disponvel. Na MMWA, cada representao abstrata composta por vrias representaes
concretas, que podem ser implementadas na forma de padres de projeto ou componentes
56
como ser apresentado mais adiante. Uma representao concreta pode agrupar vrias tarefas
abstratas, por exemplo, o projetista pode criar a tarefa InformarData do tipo Seleo e
utilizar o padro de projeto Date Selection, que permite ao usurio informar a data com o
dia, o ms e o ano utilizando uma ou mais modalidades, de uma nica vez ou um item de
cada vez.
O comportamento especificado na forma de aes, que so responsveis por
sincronizar as tarefas e dar continuidade interao. Uma ao disparada por um evento
em uma determinada tarefa e pode ser tratada dentro da mesma tarefa ou em uma outra
tarefa.
possvel identificar opes nessa atividade. Uma opo uma deciso feita pelo
usurio que pode levar a diferentes caminhos, com diferentes aes, a partir de uma tarefa.
Opes so geralmente utilizadas na especificao das gramticas das interfaces de voz e na
verificao do fluxo da aplicao, pois guardam dados sobre o fluxo da interao.
No Quadro 3 possvel visualizar parte de um documento de projeto de interfaces
obtido com o uso da MMWA representando: as tarefas previamente identificadas (Figura 12
e Figura 13), os elementos de interface grfica (GUI widgets) e os elementos da interface de
voz (VUI), as aes e mtodos que disparam eventos de renderizao de mapas bem como
eventos de sincronizao de GUI e VUI.
Quadro 3 - Sincronizao das interfaces de voz e grfica do segundo estudo de caso
Tarefas GUI
Widget
VUI Widget Eventos Funo de
sincronizao
T1 place1Input choose_place_1 C1,C4,C5: Focus/ Recognition setPlace1()
T2 place2Input choose_place_2 C2 and C3: Focus/ Recognition setPlace2()
T3 get_directio
ns
confirm_choices C6: Blur / OnClick confirmDirection()
T4 stepText Step_commands C7: Focus / OnClick writeNextStep()
writeBackStep()
Na execuo dos estudos de caso, observou-se a necessidade da criao de uma
ferramenta para automatizar o processo de Anlise de Tarefas pela equipe de projeto e
desenvolvimento. Portanto, os requisitos para a criao de ferramentas de software baseadas
em Anlise de Tarefas descritos em (WELIE; VAN DER VEER; ELINS, 1999) foram
considerados no desenvolvimento do ambiente de autoria que foi desenvolvido neste projeto
e ser apresentado no prximo captulo, a saber:
57
" A ferramenta deve ser projetada fundamentando-se em um framework conceitual.
Todo o modelo de tarefa utilizado neste trabalho obtido a partir das
especificaes abstratas e concretas das interfaces e utilizando-se os conceitos de
aes e opes. Com essa utilizao do modelo de tarefas a organizao da
informao fica mais completa e aspectos importantes que so inerentes a
multimodalidade so includos tanto no projeto quanto na documentao e no DR
para reutilizao futura.
" Oferea uma representao coerente e consistente. Existem diversas
representaes para realizar anlise de tarefas, no entanto, a ferramenta que serve
de framework para esta abordagem implementa um mecanismo simplificado.
Toda a representao realizada na forma de uma rvore de tarefas e links entre
elas. A visualizao pode ser vista diretamente no prottipo de interface.
" Permita que os projetistas interajam entre si para a criao da Anlise de Tarefas.
A abordagem prev a colaborao por meio da utilizao de sistemas Wiki que
so responsveis pela captura e o armazenamento de DR. Dessa forma possvel
facilitar as discusses entre projetistas e utilizar o raciocnio de projetos anteriores
aproveitando o conhecimento previamente gravado.
" Fornea suporte documentao. A fase de projeto na MMWA realizada de
forma a promover a documentao de todas as atividades previstas.
" Permita controle de verses de projetos. A utilizao de Wiki prev o uso de
controle de verses por natureza. As decises que so tomadas e os comentrios
so gravados na forma de DR.
4.6 Anlise das Solues (AS)
A quarta atividade da MMWA, representada na Figura 15, consiste na Anlise das
Solues obtidas nas atividades anteriores da abordagem. Os projetistas utilizam o DR
previamente capturado, filtram as opes de interao e escolhem estratgias de dilogo e de
preveno de erros fundamentando-se na argumentao dos especialistas no domnio.
Esta atividade fornece as potenciais modalidades para serem usadas para completar
uma tarefa, a sua representao concreta e o DR inerente. Ao final desta atividade so
gerados um documento de projeto, contendo informaes sobre requisitos, anlise de tarefas,
modelo do dilogo, fluxo da aplicao e o protocolo de testes de usabilidade, bem como um
58
prottipo de interface para ser avaliada na prxima atividade de testes. Na MMWA tambm
so consideradas as propriedades CARE apresentadas em (COUTAZ et al., 1995).
Figura 15 - MMWA: Anlise de Solues
Nesta tese de doutorado so consideradas duas modalidades de interao: interao
grfica com o uso de manipulao direta (mouse, teclado, dispositivos de toque), e interface
de voz. Contudo, outras modalidades podem ser includas no futuro, pois o modelo de tarefas
foi planejado para poder ser estendido com a incluso de novas modalidades.
Para cada alternativa de projeto existe uma lista com os possveis valores que os itens
de interface podem assumir associando-se ao mesmo tempo a propriedade CARE
correspondente.
Na Figura 16 apresentado um trecho do documento de projeto gerado com o uso da
MMWA. possvel verificar os dilogos (estados) que correspondem s tarefas
T2:ChooseDestination (escolher local de chegada) e T3:ConfirmPlaces (confirmar pontos de
interesse), bem como os elementos das interfaces de voz e das interfaces grficas
correspondentes, e os eventos associados com essas interfaces e as transies ou mensagens
que conectam essas tarefas. Por exemplo, possvel verificar que um evento de foco
(onFocus) lanado no elemento da interface grfica place2Input, o tratador desse evento
no formulrio interface de voz choose_place_2 ativado para capturar a fala do usurio.
Desse ponto, caso haja um evento de reconhecimento (OnRecognition) ou um evento de
transferncia de foco (OnBlur) o mapa ser atualizado com o lugar de chegada que o usurio
escolher. Quando a atualizao do mapa for realizada (OnBlur), o estado T3, que representa
uma tarefa de confirmao ativado e o sistema apresenta a rota conectando os dois pontos
selecionados pelo usurio (tarefas T1 e T2).
Captulo 4
para cada tarefa do segundo estudo de caso, as representaes abstrata e concreta, as
propriedades CARE e a
MMWA.
tarefas e que podem ser utilizados na especificao das interfaces multimodais como
representao concreta, bem como o exemplo de sua utilizao em interfaces grficas (GUI) e
de voz (VUI) e as propriedades CARE que pode
dilogo, preveno e correo de erros, confirmao e sincronizao de interfaces, podem ser
utilizadas durante o projeto de interfaces mul
Figura
Outro trecho de um outro documento de projeto,
propriedades CARE e a
MMWA.
No Captulo 5
Conforme ser apresentado nas sees seguintes, algumas estratgias como as de:
Figura 16 - Trecho do Documento de Projeto obtido com a MMWA
propriedades CARE e a estratgia de dilogo escolhida pelo projetista durante o uso da
Captulo 5 sero elencados os elementos (
Trecho do Documento de Projeto obtido com a MMWA
stratgia de dilogo escolhida pelo projetista durante o uso da
sero elencados os elementos (
59
sero elencados os elementos (
de voz (VUI) e as propriedades CARE que podem ser escolhidas na fase de projeto.
utilizadas durante o projeto de interfaces multimodais com o uso das modalidades grfica e
Outro trecho de um outro documento de projeto, apresentado n
sero elencados os elementos (widgets) implementados no modelo de
m ser escolhidas na fase de projeto.
timodais com o uso das modalidades grfica e
ces Multimodais
apresentado no
) implementados no modelo de
Quadro 4, mostra,
(MMWA)
, mostra,
60
de voz com a finalidade de aumentar a usabilidade e consequentemente os nveis de
satisfao dos usurios.
Quadro 4 - Trecho do documento de projeto do segundo estudo de caso
Tarefa Representao
Abstrata
Propriedades
CARE
Estratgia de dilogo Representao
Concreta
RealizarPagamento Navegao R,E interao iniciada pelo
usurio + preenchimento de
slot + confirmao tardia
Menu
ReproduzirEscolha Sada A Prompt de afirmao Prompt de Sada
SelecionarCartao Agrupamento - Iniciativa mista Formulrio
PerguntarTipo Sada R interao iniciada pelo
sistema
Prompt Inicial +
Label
EscolherCartao Seleo R;E preenchimento de slot +
Sincronizao
ComboBox +
Gramtica
ReproduzirEscolha Sada A Prompt de afirmao Prompt de Sada
4.6.1 Sincronizao entre modalidades diferentes
A sincronizao um tpico especfico das aplicaes multimodais, pelo fato de que a
aplicao multimodal apresenta a informao ao usurio em diversas modalidades, por
exemplo, com o uso de interfaces grfica e de voz. A interao por voz pode ser considerada
como temporal, enquanto a interao visual grfica pode ser considerada espacial. Quando
combinadas em uma interface multimodal, as interfaces precisam estar sincronizadas para
no comprometer a usabilidade do sistema.
No projeto da aplicao multimodal necessrio considerar que as transies do
dilogo envolvem ambas as interfaces. Por exemplo, quando a interface de voz processar um
dilogo na primeira pgina, a interface grfica no deve ser levada pgina seguinte a menos
que a interface de voz estiver fazendo tambm uma transio a essa pgina. Se o usurio
forar a transio pela interface grfica, a interface de voz deve se ajustar conformemente,
parando o processo na primeira pgina e comeando o processo para a pgina seguinte ou
disparando uma mensagem de erro. A interface grfica deve atualizar a pgina para mostrar
tambm a resposta de voz.
Alm de sincronizar as transies de dilogo as transies entre elementos tambm
devem ser realizadas. Se o controle da voz se mover de um campo de texto para uma lista, o
foco visual deve ser movido tambm do campo de texto para a lista. O contrrio tambm
precisa acontecer, quando o preenchimento feito por voz, o foco muda para o campo visual
correspondente.
61
4.6.2 Ativao de tarefas e estratgia de dilogo
O dilogo, de acordo com Allen e seus colegas (ALLEN et al., 2001), enriquece a
interao e permite que informaes mais complexas do que uma mensagem falada sejam
trocadas entre dois agentes. O objetivo de se utilizar interfaces de voz e sistemas com dilogo
aumentar o desempenho da interao humana utilizando a fala e seu aspecto mais
importante a criao de um contexto de dilogo, o qual permite ao sistema antecipar e
prever as necessidades do usurio.
Em um dilogo entre dois agentes, o agente que conduz a conversa em um
determinado momento considerado como o detentor da iniciativa. Portanto, uma interao
iniciada pelo sistema aquela na qual o sistema controla o fluxo do dilogo com um
usurio, por exemplo, oferecendo perguntas bem especficas ao usurio e esperando respostas
especficas. Em contrapartida, os sistemas com interao iniciada pelo usurio so aqueles
que permitem que o usurio detenha o controle da interao, permitindo maior flexibilidade
no que o usurio pode dizer. Dependendo da fala do usurio, o sistema pode oferecer uma
nova pergunta para retirar a ambigidade da frase. Um dilogo com iniciativa mista aquele
no qual o usurio e o sistema se revezam no controle do fluxo do dilogo.
Existem quatro nveis de iniciativa mista (ALLEN; GUINN; HORVTZ, 1999). A
forma mais simples de interao por iniciativa mista a no solicitada, que permite a um
agente fornecer a informao a qualquer momento. A iniciativa por subdilogo permite que
um agente detenha a iniciativa do dilogo durante a execuo de um subdilogo e, em
seguida, retorne a iniciativa ao outro agente. A iniciativa por tarefa permite que o agente
mantenha a iniciativa em uma tarefa e interaja com outro agente quando for necessrio. E por
ltimo, no mais alto nvel, os agentes podem negociar quem ter a iniciativa e continuar a
interao.
Dependendo do projeto, uma abordagem mais rgida pode ser utilizada para a criao
do dilogo por iniciativa mista, por exemplo, limitando as possibilidades do usurio
influenciar no fluxo do dilogo. Em tais projetos, os usurios podem fornecer somente as
informaes solicitadas pelo sistema e podem executar controles bsicos sobre o dilogo
como: pedir ajuda, solicitar que o sistema repita a informao ou comear a interao
novamente. Este tipo de dilogo chamado de dilogo dirigido pelo sistema. Uma estratgia
mais restrita ainda pode usar uma abordagem similar ao preenchimento de formulrios das
interfaces grficas convencionais na qual o usurio pode somente fornecer as informaes,
que o sistema solicita em seus prompts, em frases curtas ou com apenas uma palavra.
62
4.6.3 Estratgias de gerenciamento do dilogo
Uma questo crtica nos sistemas de voz o gerenciamento do dilogo. Na viso de
(MCTEAR, 2002), o gerenciador do dilogo desempenha o papel de mediador entre o usurio
e um sistema de informao. Ele deve determinar se foi obtida informao suficiente do
usurio para permitir a comunicao com a aplicao, executar as transaes necessrias e
retornar os resultados para o usurio.
Durante o processamento de linguagem natural, as palavras reconhecidas devem ser
analisadas para determinar o que o usurio disse. A estratgia pode ser simples como
comparao por palavras-chave ou o dilogo pode usar algoritmos sofisticados para entender
a fala humana.
O gerenciador do dilogo geralmente usa algumas tcnicas como anlise da fala,
contexto do discurso, modelos de estrutura de dilogo para interpretar falas no reconhecidas
ou mal formadas (TRAUM et al., 1996). Em caso de falha, o sistema pode recorrer a recursos
como soletrar palavras.
A estratgia de controle do dilogo varia conforme a complexidade do sistema. Isto
envolve decidir o que o usurio pode ou no ter que dizer.
Geralmente, a estratgia seguida no gerenciamento do dilogo em um sistema de voz
a de preenchimento de espaos ou slots (SOUVIGNIER et al., 2000), na qual somente
valores para slots previamente definidos so aceitos, enquanto que, em um dilogo com
iniciativa mista o usurio pode fornecer quanta informao ele quiser, possivelmente com
valores que no esto especificados nos prompts, para os slots. A tarefa do gerenciador do
dilogo preencher cada slot para cumprir o objetivo do dilogo com o usurio e manter o
dilogo o mais breve possvel. Para tanto comum que o projetista de uma VUI solicite
informaes para preencher o slot com o mximo de desambiguao, durante o processo de
criao de uma VUI.
4.6.4 Estratgia de preveno e correo de erros
Aps a escolha da estratgia de dilogo, necessrio tratar da questo de como lidar
com os elementos importantes desse dilogo, como a descoberta e recuperao de erros e os
comandos universais (MCGLASHAN, 1999).
A recuperao de erros necessria, pois nem a tecnologia nem os seres humanos so
perfeitos. Todo reconhecedor de voz atribui um grau de confiana relacionado ao que foi dito
pelo usurio e esse grau de confiana pode ser baixo, quando o reconhecedor ainda no
estava pronto para aceitar a fala do usurio ou no ter ouvido o que ele disse, ou quando o
63
usurio fala uma frase muito complexa que no permite gerar uma hiptese de
reconhecimento.
Os usurios freqentemente encurtam suas palavras, permanecem silenciosos,
fornecem informao irrelevante, podem pressionar teclas impulsivamente quando o sistema
est esperando uma entrada por voz e podem estar em diversos tipos de ambientes. Por isso,
um projeto de aplicao de voz deve incluir mecanismos para tratar essas situaes e permitir
que o usurio possa fornecer a informao novamente ou obter ajuda at que consiga
completar sua tarefa.
O projetista de interao multimodal deve considerar as duas mensagens mais comuns
retornadas pelo reconhecedor que so rejeio ou nomatch, quando nenhuma hiptese
encontrada, e limite de tempo sem fala, quando nada ouvido ou captado pelo
reconhecedor.
Uma abordagem comum para retomar o dilogo depois da ocorrncia de uma rejeio
a chamada progressiveprompting, na qual o sistema fornece informaes mais detalhadas
e/ou exemplos do que o usurio pode dizer. Se mais erros forem ocorrendo, mais detalhes
devem ser fornecidos (WEINSCHENK; BARKER, 2000).
Outra abordagem o rapid reprompt, na qual o sistema ao invs de fornecer
informao detalhada, reage ao erro com uma rpida fala, por exemplo, o que voc disse?,
para indicar que ele no entendeu o que foi dito. Se outro erro ocorrer, o comportamento pode
seguir a estratgia anterior fornecendo informaes mais detalhadas do que pode ser dito
(LAI et al., 2002).
A escolha da abordagem depende da tarefa. A desvantagem do progressive prompting
que o usurio pode ficar impaciente com mensagens de erros detalhadas e a desvantagem
do rapid reprompt, que os usurios que no esto seguros sobre o que dizer passam por um
passo a mais para recuperar do erro.
O comportamento apresentado para o caso de rejeio tambm pode ser adotado para
o caso do limite de tempo sem fala, mas deve ficar claro para o usurio que o sistema no
conseguiu ouvi-lo, mesmo que o restante da mensagem for a mesma. Deve-se ficar atento
para o uso de rapid reprompt, pois em muitos casos o usurio permanece em silncio quando
ele no est certo do que dizer, neste caso essa estratgia no to eficiente como para o caso
de rejeio.
importante salientar que esse tipo de abordagem mais fcil de se implementar em
uma interface grfica convencional, pois a modalidade grfica ou visual permite que o
projetista possa fornecer informaes mais detalhadas e ao mesmo tempo reagir ao erro de
64
uma forma rpida destacando o local de sua ocorrncia. Dessa forma, um usurio impaciente
fica ciente do problema sem a necessidade de ler a mensagem detalhada. Esta questo torna-
se fundamental para o desenvolvimento deste projeto, pois ser necessrio pesquisar
mecanismos para melhor apresentar esse tipo de informao de maneira multimodal ao
usurio.
Na MMWA quando um erro do tipo nomatch ocorre e o projetista est utilizando
multimodalidade, ou seja, interfaces de voz e grfica na mesma tarefa, a estratgia escolhida
para recuperao do erro o sistema tocar um prompt definido pelo projetista, que pode
conter exemplos de falas e ao mesmo tempo um destaque dado na interface grfica para
permitir ao usurio trocar de modalidade de uma forma mais rpida e eficiente, pois o
destaque alerta o usurio em qual parte da tela a informao deve ser fornecida. Este destaque
pode ser implementado como um grifo, uma troca de cor de fundo ou at mesmo expandindo
uma caixa de seleo para que o usurio veja as opes disponveis.
4.6.5 Estratgia de comandos Universais
Um bom projeto tambm deve fornecer aos usurios comandos de controle da
interao que ajudam na preveno de erros e esto sempre disponveis durante toda a
aplicao em qualquer momento e em qualquer estado de dilogo, os chamados comandos
universais. Os comandos universais so implementados em uma gramtica paralela e oferece
as opes de comandos que permitem possibilitar ao usurio pedir ajuda, solicitar que o
sistema repita uma frase ou ainda comear de novo ou voltar uma tarefa (MCGLASHAN,
1999).
Em uma GUI, o usurio usa mecanismos convencionais que precisam estar presentes
na interface, por exemplo, um cone de interrogao com significado de obter ajuda. J em
uma VUI, o usurio solicita que o sistema repita uma informao. Em uma interao
multimodal, o usurio solicita ajuda e sistema l o prompt indicando o local que o usurio
deve fornecer uma informao.
4.6.6 Mecanismo de confirmao global/por tarefa
Tanto os seres humanos como sistemas que tentam entender entrada natural cometem
erros. No entanto, os seres humanos confirmam a entrada duvidosa. O dilogo fica
prejudicando quando no existe um meio de reconhecer erros, pedir uma clarificao do que
foi dito ou tirar a ambiguidade de uma entrada.
65
Para assegurar que o dilogo tenha continuidade em uma tarefa, os projetistas devem
decidir como realizar a confirmao, para quais modalidades, e em que momentos do dilogo.
Na estratgia de confirmao antecipada, a entrada do usurio imediatamente
transmitida a seu respectivo reconhecedor, uma hiptese de reconhecimento retornada para
a interface e a confirmao ou a retirada de ambiguidade realizada. Em sistemas
multimodais, as interpretaes com maior probabilidades podem ser apresentadas ao usurio
e este pode usar a modalidade mais conveniente para confirmar a sua entrada. O problema
ocorre quando os usurios utilizam a multimodalidade de maneira complementar, ou seja,
uma entrada fornecida em duas ou mais etapas utilizando mais de uma modalidade. Neste
caso a integrao no realizada, pois a confirmao ocorre medida que as entradas vo
sendo fornecidas ao sistema.
Uma soluo para esse problema previamente apresentado a utilizao de
confirmao tardia para garantir que as expectativas dos usurios sejam atingidas por meio da
integrao entre as modalidades. Nesse caso, o sistema espera a integrao de todas as
modalidades para verificar se a retirada de ambiguidade pode ser feita antes de realizar a
confirmao com o usurio.
Suponha que o usurio est interagindo com o mapa do Brasil utilizando manipulao
direta (interface grfica). O usurio deseja selecionar o estado de Sergipe, mas no momento
do toque ou clique o reconhecedor no entende se o usurio desejou selecionar Sergipe ou
Alagoas, pois a rea de toque disponvel muito pequena (os estados so bem pequenos e
fazem fronteira). Caso no haja confirmao, h uma chance grande do sistema selecionar o
estado incorreto. Caso haja confirmao antecipada o sistema pode no considerar uma
entrada de fala que tiraria a ambiguidade da interao. Caso a estratgia utilizada seja a
confirmao tardia e o usurio diga Sergipe, o usurio no perceber nenhum problema de
interao.
4.7 Avaliao de Usabilidade (AU)
A quinta e ltima atividade que completa o ciclo da MMWA a avaliao de
usabilidade que realizada com o uso do prottipo gerado a partir das atividades anteriores.
Para avaliar a usabilidade das interfaces multimodais importante considerar como
requisito primrio suas especificidades tais como as modalidades disponveis e a linguagem
de interao escolhida pelo usurio.
66
A literatura indica que as abordagens preferidas para a avaliao de usabilidade no
contexto das interfaces multimodais so aquelas que utilizam simulaes (LOPEZ-CEZAR et
al., 2003) e testes com usurios reais executando tarefas pr-definidas no prottipo gerado
(BERNHAUPT, 2008), pois assim possvel descobrir problemas de usabilidade bem como
investigar os padres de interao do usurio e obter informaes importantes sobre
experincia de uso. Da mesma forma, sabe-se que mtodos empricos e analticos so
complementares (DESURVIRE, 1994), portanto neste trabalho so considerados ambos com
a finalidade de obter melhores resultados.
A atividade de avaliao de usabilidade composta por um mecanismo de avaliao
heurstica (MMHE) e um mecanismo automtico para a gerao, coleta e anlise de logs em
Testes com Usurios remotos (MMLOG), descritos na sequncia.
No final da quinta atividade, o prottipo melhorado com as sugestes de correes
de erros obtidas com as avaliaes de usabilidade e o ciclo reinicia para que as novas
caractersticas obtidas utilizando-se o DR gravado para cada iterao da MMWA sejam
utilizadas. A atividade de AU esquematizada na Figura 17 e os detalhes so apresentados
nas sees 4.7.1 e 4.7.2.
Figura 17 - MMWA: Avaliao de Usabilidade
4.7.1 Mecanismo de avaliao heurstica em interaes multimodais Web
(MMHE)
Na abordagem MMWA foi definido um mecanismo para a realizao de Avaliaes
Heursticas, no qual utiliza-se o relacionamento de um conjunto de checklists obtidas a partir
da proposta de 10 princpios de usabilidade para interfaces multimodais, relacionados com as
67
10 heursticas de Nielsen (1990) como uma forma de caracterizar e definir a presena de
aspectos de usabilidade em um projeto de interao multimodal.
Os princpios, detalhados a seguir, devem ser utilizados como uma forma de facilitar a
identificao de problemas de usabilidade na interao multimodal e tambm explicitar boas
prticas em nvel de projeto que sejam identificados por seus projetistas.
1. Sincronizao. As mltiplas modalidades devem estar sincronizadas. A
interao por voz pode ser considerada como temporal, enquanto a interao
visual grfica pode ser considerada espacial (JURAFSKY; MARTIN, 2000).
Quando combinadas em uma interface multimodal, esses modos de interao
precisam estar sincronizados para no comprometer a usabilidade do sistema.
2. Transio Perceptvel. A transio entre dilogos em uma interao
multimodal deve ser perceptvel ao usurio, pois as suas habilidades e
necessidades, bem como o contexto de uso podem ser modificado durante a
interao.
3. Compartilhamento do Estado de interao. As mltiplas modalidades
devem compartilhar o estado de interao para que durante a mudana de uma
interface para outra ou se o usurio desejar trocar de modalidade em uma
determinada seqncia do dilogo humano-computador, as vrias mdias
disponveis sejam atualizadas.
4. Previsibilidade. As interfaces multimodais devem ser previsveis, ou seja, a
interface precisa possibilitar que o usurio saiba intuitivamente qual o melhor
modo para se utilizar durante a execuo de uma tarefa.
5. Adaptao. As interfaces multimodais devem se adaptar ao ambiente do
usurio para assegurar que o melhor modo de se completar uma determinada
tarefa em um determinado momento estar disponvel ao usurio. A
adaptatividade tambm considerada como uma guideline. A adaptatividade
dinmica permite que a transio entre dilogos em uma interao seja
perceptvel ao usurio por meio de modalidades complementares.
6. Diversidade de usurios e dispositivos de interao. Durante a
especificao de requisitos, o projeto da interao multimodal deve ser
pensado para uma grande gama de usurios e contextos de uso. Alm disso, o
projetista deve considerar questes de privacidade e de segurana.
7. Projeto da entrada e sada multimodal. O projetista deve utilizar o recurso
de mltiplas modalidades para maximizar as habilidades humanas cognitivas e
68
fsicas. Alm disso, deve-se evitar a apresentao de informaes
desnecessrias nas diferentes modalidades, com o objetivo de maximizar as
vantagens de cada modalidade para reduzir a carga de memria do usurio
durante a execuo de uma tarefa. importante tambm integrar as
modalidades de maneira compatvel com as preferncias do usurio, contexto
e funcionalidades do sistema.
8. Consistncia na interao. As Interfaces visuais e de voz devem
compartilhar ao mximo as caractersticas comuns e devem se referenciar a
uma tarefa com a mesma terminologia nas diferentes modalidades.
9. Retorno (feedback). Os usurios devem perceber que modalidades esto
presentes em determinado momento da interao e devem perceber quais so
os tipos de interao alternativas que esto presentes para executar uma tarefa.
10. Tratamento e preveno de erros. Deve haver validaes e elementos de
interface que proporcionem clareza em sua utilizao com feedback do
resultado da interao seja por voz ou via mensagens grficas.
Esses princpios, utilizados em conjunto com as heursticas e as checklists, tambm
podem ser usados para estruturar o processo de desenvolvimento como ferramenta de
consulta associada ao design rationale coletado em projetos anteriores e protocolos de
avaliao podem ser propostos observando-se a definio de cada princpio e os diferentes
nveis de granularidade das checklists. Algumas formas de organizao desses conceitos, que
foram utilizadas nos estudos de caso podem ser encontradas no Apndice B.
A primeira etapa do MMHE (MultiModal Heurist Evaluation Mechanism) consiste
na preparao do formulrio de avaliao. No incio da utilizao da MMWA, esse
formulrio era hospedado em uma Wiki para permitir a edio colaborativa e a captura e o
armazenamento de DR, mas com a criao do ambiente de autoria que implementa a MMWA
(o MMWA-ae), esse formulrio passou a ser utilizado dentro da ferramenta conforme pode
ser observado na Figura 18.
A elaborao deste formulrio fundamenta-se nas dez heursticas gerais de Nielsen
(NIELSEN, 1993), considerando-se tambm um conjunto de Heursticas para a Web
(SHNEIDERMAN, 1998; NIELSEN; TAHIR, 2001; NIELSEN, 2006) como complemento, e
no seu relacionamento com os princpios multimodais previamente definidos e com a sua
associao com os itens disponveis nas checklists para guiar os avaliadores na busca de
problemas relacionados aos princpios definidos neste trabalho.
Captulo 4
abordar/resolver os problemas de usabilidade encontrados durante a Avaliao Heur
Alm disso, o relacionamento dessas teorias permitiu o de
sugestes de solues utilizado na ferramenta de autoria que serve como
abordagem, pois atribu
usabilidade e essas informaes podem ser ranquead
uma soluo, baseada em um DR gravado anteriormente, como ser apresentado mais adiante
no Captulo 7
Tarefa, Heurstica, Princpio,
severidade dos problemas pode ser definida atravs da seguinte escala: (0) caso no seja um
problema de usabilidade; (1) caso o problema seja sem relevncia: no preci
com urgncia; (2) caso o problema de usabilidade tenha uma prioridade baixa de correo;
(3) caso o problema de usabilidade tenha alta prioridade de soluo e (4) caso a correo deva
ser realizada antes do produto ser liberado.
testadores durante a captura e o armazenamento dos problemas encontrados e tambm
O resultado uma maneira mais organizada de descrever, docume
abordagem, pois atribu
Captulo 7.
A verso final do formulrio possui 6 campos, como pode ser observado na
O objetivo principal da preparao do formulrio de avaliao fornecer um guia aos
abordagem, pois atribudo um conjunto de informaes a um determinado problema de
Figura 18 -
do um conjunto de informaes a um determinado problema de
Tarefa, Heurstica, Princpio, Checklist
- MMHE: Formulrio de avaliao heurstica
69
Checklist, Descrio Problema e Severidade; sendo que a
MMHE: Formulrio de avaliao heurstica
Alm disso, o relacionamento dessas teorias permitiu o desenvolvimento do mecanismo de
usabilidade e essas informaes podem ser ranqueadas e usadas para a escolha automtica de
, Descrio Problema e Severidade; sendo que a
ces Multimodais
senvolvimento do mecanismo de
sugestes de solues utilizado na ferramenta de autoria que serve como framework
as e usadas para a escolha automtica de
framework para esta
A verso final do formulrio possui 6 campos, como pode ser observado na Figura
problema de usabilidade; (1) caso o problema seja sem relevncia: no preci sa ser corrigido
(MMWA)
O resultado uma maneira mais organizada de descrever, documentar e
abordar/resolver os problemas de usabilidade encontrados durante a Avaliao Heurstica.
para esta
Figura 18:
sa ser corrigido
70
permitir que as solues para os problemas resolvidos sejam facilmente localizadas em um
projeto subsequente, assim todo o DR obtido, inclusive em outras atividades da abordagem,
pode ser encontrado e referenciado.
Na segunda etapa, o objetivo aplicar o formulrio para avaliar os prottipos a fim de
verificar se os princpios multimodais esto presentes no projeto, relatando as falhas quanto
ao cumprimento dos princpios de usabilidade e das heursticas. Essa fase envolve um grupo
de no mnimo quatro avaliadores, experientes em avaliao heurstica, que examinam as
interfaces de maneira impessoal, julgando se atendem aos princpios definidos. Os principais
problemas encontrados e sua relao com as heursticas por meio de checklists so gravados
na forma de DR e discutidos posteriormente entre os avaliadores, gerando uma lista nica
com todo o raciocnio envolvido na identificao e correo dos problemas encontrados. Esse
DR gravado pode tambm ser consultado pelos desenvolvedores em outras iteraes da
MMWA ou outros projetos aplicando a MMWA. No Quadro 5 pode ser observado um trecho
do formulrio de avaliao heurstica que foi utilizado em um dos estudos de caso realizados
no transcorrer deste trabalho.
Quadro 5 - Trecho do formulrio de avaliao heurstica
Heurstica Checklist Princpios Problema Severidade
Preveno de
Erros
O sistema multimodal
faz com que usurios
cometam erros que no
cometeriam em
sistemas apenas com
interface visual?
Tratamento e
preveno de
erros
O usurio no sabe o que dizer
quando ele quer deixar um
campo opcional no
preenchido. No fornecida
assistncia apropriada quando
um erro ocorre.
4
Flexibilidade e
Eficincia
possvel ao usurio
selecionar se deseja ou
no que sejam lidas as
listas de opes da
caixa de seleo?
Previsibilidade
Reconhecimento
ao Invs de
Memorizao.
Existe algum modo
indisponvel em um
determinado momento
da interao?
Consistncia na
Interao.
O usurio no sabe o contedo
interno de uma caixa de seleo
e no tem outra alternativa a
no ser utilizar a interface
grfica, ou seja, o modo voz
est disponvel, mas o usurio
no sabe o que pode dizer
4
Visibilidade do
status do
sistema.
As listas de opes das
caixas de seleo esto
claras para o usurio?
Interfaces
Previsveis.
4.7.2 Mecanismo de gerao e anlise automtica de log em interaes
multimodais Web (MMLOG)
A proposta do MMLOG permitir a realizao de Testes com Usurios remotos,
anlise estatstica das interaes e reconhecimento de padres de interao multimodal. Uma
das vantagens desse mecanismo que um grande grupo de usurios pode ser facilmente
Captulo 4
recrutado, pois os testes podem ser executados remotamente e no horrio mais conveniente ao
usurio.
execuo do MMLOG, que sero abordados no
testes explicando a proposta da avaliao de usabilidade e a descrio das tarefas ou cenrio
de uso a serem executados, a criao de um questionrio de satisfao de uso, a existncia de
um canal direto com os realizadores dos testes, entre outros.
a captura de
modalidade escolhida pelo usurio, a fala do usurio e o tempo de interao com cada
da interface
utilizam
usurio.
O mecanismo de testes com usurios remotos requer alguns cuidados durante a
e uso a serem executados, a criao de um questionrio de satisfao de uso, a existncia de
Para que a avaliao da usabilidade nesse tipo de teste seja eficiente faz
a captura de todos os eventos que ocorrem durante a interao multimodal, bem como a
da interface, como
Os atributos de interao podem ser configurveis para cada projeto, mas geralmente
utilizam-se os seguintes atributos como padro:
" SessionID
usurio interagindo com a aplicao multimodal.
" Modalidade
elemento da interface;
" Interface
mecanismo de testes com usurios remotos requer alguns cuidados durante a
todos os eventos que ocorrem durante a interao multimodal, bem como a
ilustrado na
Figura
atributos de interao podem ser configurveis para cada projeto, mas geralmente
se os seguintes atributos como padro:
SessionID: um identificador nico da interao que serve para identificar um
Modalidade: a modalidade escolhida pelo usurio para interagir com um
Interface: o nome da interface/
a Figura 19
Figura 19 - Fluxo de interao do MMLOG
identificador nico da interao que serve para identificar um
: a modalidade escolhida pelo usurio para interagir com um
nome da interface/
71
execuo do MMLOG, que sero abordados no Captulo 5
19.
Fluxo de interao do MMLOG
nome da interface/widget em que a interao est acontecendo;
Captulo 5, como
em que a interao est acontecendo;
ces Multimodais
, como: a criao do protocolo de
: a criao do protocolo de
Para que a avaliao da usabilidade nesse tipo de teste seja eficiente faz-se necessria
(MMWA)
: a criao do protocolo de
se necessria
modalidade escolhida pelo usurio, a fala do usurio e o tempo de interao com cada widget
72
" Tarefa: a tarefa que o usurio est executando;
" Valor: o valor de entrada fornecido pelo usurio;
" Interpretao: a interpretao do sistema para uma Entrada do usurio;
" Confiana: um valor probabilstico associado pelo reconhecedor de voz a uma
entrada de voz do usurio;
" Tempo: o tempo gasto pelo usurio para interagir com a interface/widget;
O MMLOG foi desenvolvido para coletar logs em qualquer interface multimodal Web
desenvolvida seguindo os padres do W3C. O MMLOG composto por 4 classes e 8
mtodos, apresentados na sequncia (Figura 20) que habilitam uma coleta estruturada de logs,
utilizados para gerar grficos e tabelas permitindo a anlise estatstica das escolhas de
interao por parte do projetista de interface alm de viabilizar e facilitar a percepo e
descoberta de padres de interao (OVIATT; COULSTON; LUNSFORD, 2004) de grupos
de usurios e at mesmo erros de projeto de interao multimodal e problemas de
usabilidade.
Figura 20 - MMLOG: Diagrama de Classe
O significado de cada classe e mtodo est descrito a seguir:
73
" Classe I nteraction: contm os dados da interao de um usurio, como o nome,
idade, sexo, idioma, data, hora, identificador nico da sesso.
" Classe Graphical: contm informaes sobre a interface grfica como o
identificador da widget e o valor utilizado pelo usurio para completar sua tarefa.
" Classe Voice: contm informaes da interface de voz, como o identificador da
tarefa, a interpretao obtida para uma fala, a representao em texto da fala do
usurio e a confiana que o reconhecedor de voz atribui para uma entrada do
usurio.
" Classe Voice_Event: contm informaes sobre os tipos de eventos que podem
ocorrer na interface de voz, como eventos de erro, confirmao e sincronizao.
" Mtodo StartI nteraction: registra a hora que a interao comeou.
" Mtodo EndI nteraction: registra a hora que a interao terminou.
" Mtodo WrongI nteraction: fundamentado no protocolo de testes de usabilidade
possvel informar ao modelo de tarefas que o usurio completou uma determinada
tarefa com dados errados.
" Mtodo CorrectI nteraction: fundamentado no protocolo de testes de usabilidade
possvel informar ao modelo de tarefas que o usurio completou uma
determinada tarefa com dados corretos.
" Mtodo logGUI Event: grava na base de log, uma interao realizada pelo usurio
com uma widget grfica.
" Mtodo logVUI Event: grava na base de log, uma interao realizada pelo usurio
com uma widget de voz.
" Mtodo logVUI ErrorEvent: caso haja um erro na interface de voz, por exemplo
de interpretao, possvel gravar no log informaes sobre o que aconteceu na
tarefa.
" Mtodo logVUI UniversalEvent: eventos universais tambm podem ser gravados
no log.
Captulo 4
modelo
identificados.
grficos e tabelas, por exemplo
possveis problemas de usabilidade, como apresentado na
verificar os tipos de erros que ocorreram e o nmero de usurios que cometeram esses erros.
Figura 21
forma global
para analisar comportamentos do usurio ou do sistema, como:
importante salientar que novas classes e novos mtodos podem ser inclu
modelo, caso uma nova modalidade seja adicionada MMWA, ou novos requisitos sejam
identificados.
possvel realizar diversas buscas na base de dados do MMLOG para a gerao de
21 - MMLOG: grfico que mostra o nmero e o tipo dos erros na interface de voz para
Tambm possvel c
forma global, como apresentado na
" Comparar o tempo mdio de interao para cada modalidade, dada uma mesma
tarefa.
" Obter a taxa de recuperao de erros.
" Verificar o comportamento do usurio no momento que ocorr
" Obter o perfil dos usurios (sexo, idade, regio, etc) que interagem de uma
determinada maneira.
caso uma nova modalidade seja adicionada MMWA, ou novos requisitos sejam
MMLOG: grfico que mostra o nmero e o tipo dos erros na interface de voz para
Tambm possvel comparar o uso das modalidades grfico e voz
, como apresentado na
Comparar o tempo mdio de interao para cada modalidade, dada uma mesma
Obter a taxa de recuperao de erros.
Verificar o comportamento do usurio no momento que ocorr
Obter o perfil dos usurios (sexo, idade, regio, etc) que interagem de uma
grficos e tabelas, por exemplo, realizar uma anlise de erros, por tarefa, para iden
uma tarefa
omparar o uso das modalidades grfico e voz
, como apresentado na Figura
74
, realizar uma anlise de erros, por tarefa, para iden
uma tarefa especfica
Figura 22. Outros grficos e tabelas
especfica
Outros grficos e tabelas
ces Multimodais
Figura 21
Outros grficos e tabelas
Verificar o comportamento do usurio no momento que ocorre um erro.
21, assim possvel
omparar o uso das modalidades grfico e voz, por tarefa
podem ser gerados
e um erro.
(MMWA)
importante salientar que novas classes e novos mtodos podem ser includos no
, realizar uma anlise de erros, por tarefa, para identificar
possvel
por tarefa, ou de
podem ser gerados
Captulo 4
Figura 22
4.8
1996),
descries que justificam porque determinadas estruturas foram escolhidas sobre as demais
alternativas.
mas tamb
informaes adicionais valorizam a documentao do processo, colaboram para o
aprendizado do projeto como um todo
reutiliza
apresentados
(2000),
documentao, avaliao e aprendizado de um projeto. Alm disso, pode ser bastante til
para reuso de projetos passados
de trabalho
" Gerar informaes de fluxo percorrido pelo usurio para realizar uma determinada
tarefa.
22 - MMLOG: grfico que compara o uso de dois tipos de modalidade para uma tarefa
A utilizao de
De acordo com Gruber e Russel
design rationale
alternativas. Jintae
mas tambm as justificativas, as alternativas e as argumentaes que levaram deciso. Essas
reutilizao.
Desde o surgimento dos primeiros estudos sobre
apresentados em relao
DR importante para auxiliar a execuo das atividades de reviso, manuteno,
abalho, para promoo de reflexes crticas durante o desenvolvimento de
Gerar informaes de fluxo percorrido pelo usurio para realizar uma determinada
MMLOG: grfico que compara o uso de dois tipos de modalidade para uma tarefa
tilizao de designrationale
design rationale se refere ao raciocnio que justifica um projeto resultante e as
Jintae (1997) considera que
m as justificativas, as alternativas e as argumentaes que levaram deciso. Essas
em relao adoo da abordagem na prtica. De acordo com Burge e
importante para auxiliar a execuo das atividades de reviso, manuteno,
, para promoo de reflexes crticas durante o desenvolvimento de
designrationale
se refere ao raciocnio que justifica um projeto resultante e as
considera que
adoo da abordagem na prtica. De acordo com Burge e
para reuso de projetos passados, para coordenao de pessoas que fazem parte de um grupo
75
designrationale
De acordo com Gruber e Russel (1991) e Moran
o DR abrange no apenas as decises de um projeto,
, aumentam a qualidade do produto e promove a
para coordenao de pessoas que fazem parte de um grupo
e Moran e Carroll
abrange no apenas as decises de um projeto,
aumentam a qualidade do produto e promove a
Desde o surgimento dos primeiros estudos sobre DR
ces Multimodais
e Carroll (MORAN; CARROLL,
DR, diversos be
(MORAN; CARROLL,
, diversos benefcios foram
, para promoo de reflexes crticas durante o desenvolvimento de projetos,
(MMWA)
(MORAN; CARROLL,
nefcios foram
adoo da abordagem na prtica. De acordo com Burge e Brown
rojetos, para
76
manuteno de artefatos, para auxiliar o gerenciamento dos projetos e a colaborao entre os
membros, melhorar a documentao e auxiliar na fase de engenharia de requisitos (DUTOIT
et al., 2006).
De acordo com Dutoit et al. (2006), o DR pode ser utilizado principalmente com os
seguintes propsitos:
" promover a colaborao entre membros de uma equipe;
" facilitar a manuteno e o reuso;
" melhorar a qualidade dos artefatos;
" transferir conhecimentos.
Durante o desenvolvimento de um projeto, as informaes de DR so capturadas
registrando-se o raciocnio, as decises e as alternativas de projeto com o objetivo de
construir uma estrutura formal e viabilizar a recuperao posterior das informaes. O
processo de captura de DR geralmente consiste em duas etapas: registro do conhecimento,
que envolve a captura da maior quantidade de informao possvel, e construo do
conhecimento, que se refere a extrao, organizao e armazenamento do conhecimento
(REGLI et al., 2000).
Para a representao de DR previamente capturado, necessrio que seja concebida
uma estruturao das informaes capturadas durante o desenvolvimento dos projetos, em
geral, provenientes da discusso entre os membros da equipe. O DR pode ser observado sob
diferentes perspectivas, denominadas: argumentao, comunicao e documentao, sendo
que a forma de representao das informaes varia de acordo com a perspectiva adotada
pela equipe de trabalho.
O modelo I ssue-Based I nformation System(IBIS) (KUNZ; RITTEL, 1970),
utilizado neste trabalho, faz uso de trs abstraes para representar o conhecimento,
denominadas questo, posio e argumento. Tais abstraes so relacionadas entre si para
representar a discusso dos desenvolvedores. Assim, as dvidas que surgem durante o projeto
so tratadas como questes, seguidas por uma ou mais posies que as respondem. Os
argumentos podem suportar ou rejeitar as posies, como apresentado na Figura 23.
Os relacionamentos tambm so pr-determinados pelo modelo. Projetistas que
trabalham sozinhos afirmam que a organizao de idias em termos de questo, posio e
argumento ajuda a prestar mais ateno nas partes mais difceis e crticas do problema, alm
77
de ajudar a perceber mais rapidamente as idias que estejam incoerentes. Aqueles que
trabalham em equipe consideram que a estrutura do modelo muito til e serve para mostrar
opinies dos participantes de forma clara (MONK et al., 1995).
Figura 23 - Relacionamentos do Modelo IBIS adaptado de (KUNZ; RITTEL, 1970)
O modelo IBIS incentiva a discusso de idias e, consequentemente, contribui para
que as dvidas dos desenvolvedores e dos usurios se tornem mais claras e sejam conhecidas.
Outro fator importante que o modelo IBIS suporta a comunicao entre engenheiros de
requisitos ao possibilitar que questes e possveis solues sejam compartilhadas e debatidas.
Um exemplo de DR coletado nos estudos de caso com a MMWA apresentado no Quadro 6
A recuperao de DR determinada, principalmente, pelo esquema de representao
utilizado. Algumas situaes (cenrios) que motivam a recuperao de DR se referem a
visualizao de projetos similares e suas decises associadas; a recuperao de critrios,
regras e opes que ajudem a tomar decises durante o projeto e a produo de documentos
aps o processo de projeto (REGLI et al., 2000).
Na MMWA o DR pode ser capturado em todas as atividades com a utilizao de um
sistema Wiki. Quando uma questo surge, o projetista insere o texto com a sua dvida na
Wiki e categoriza este texto como uma questo. medida que posies e argumentos vo
surgindo, estes vo sendo includos na Wiki e categorizados de acordo com o seu tipo. No
final, uma soluo proposta e todo o raciocnio fica registrado e associado com o artefato
em questo.
Nos estudos de caso iniciais com a MMWA identificou-se a necessidade da utilizao
de uma ferramenta para organizar tanto a coleta como a recuperao do DR. Na Figura 24
Captulo 4
pode-se observar que a aplicao da
futuro a recuperao desse DR poderia ser prejudicada
de DR foi includo como parte do ambiente de autoria da MMWA que ser apresentado no
prximo captulo. Nele, o projetista insere e catego
artefato, visando facilitar a organizao do conhecimento capturado e a sua futura
recuperao.
Quadro
Questo 1:
selecione um item. Vamos usar interface grfica ou de voz ou ambas?
Posio desenvolvedor1:
Argumento desenvolved
estrutura de 5 + ou
demorados para interfaces de voz, diminuindo a velocidade da
memria de curta durao do usurio.
Argumento desenvolvedor3 (contra):
reduzidos.
interface grfica?
Argumento desenvolvedor3 (a favor):
Resposta questo (Soluo):
ser apresentado ao menu de maneira visual e fazer a seleo pela fala ou clique. A parte visual deve conter
poucos itens 5+
e que sejam reconhecidos pela gramtica para habilitar o seu uso por comando de voz. O feedback de voz pode
informar em qual sub menu o usurio est. Os itens de menu podem ser falados, caso o usurio esteja usando
voz para interagir.
se observar que a aplicao da
Para solucionar este problema, o mecanismo de coleta, armazenamento e recuperao
recuperao.
Quadro 6 -
Questo 1: De acordo com o modelo de tarefas, temos que apresentar as opes ao usurio para que ele
Argumento desenvolved
estrutura de 5 + ou - 2 itens de menu recomendada para interfaces grficas, e isso pode ocasionar em
reduzidos.
interface grfica?
Resposta questo (Soluo):
poucos itens 5+-2 e no possuir muita hierarquia. os itens devem ser
voz para interagir.
Figura 24
se observar que a aplicao da
Exemplo de utilizao de DR em um estudo de caso com a MMWA
De acordo com o modelo de tarefas, temos que apresentar as opes ao usurio para que ele
Posio desenvolvedor1: vamos usar um menu de voz para a seleo das opes
2 itens de menu recomendada para interfaces grficas, e isso pode ocasionar em
Posio desenvolvedor2: que tal usar as opes mais selecionadas
Resposta questo (Soluo): em situaes em que precisamos usar interaes por voz e visual o usurio pode
2 e no possuir muita hierarquia. os itens devem ser
- Exemplo de DR capturado durante o preenchimento
se observar que a aplicao da checklist
vamos usar um menu de voz para a seleo das opes
or2 (contra): de acordo com os princpios para o desenvolvimento de interfaces, uma
Argumento desenvolvedor3 (contra): concordo com
que tal usar as opes mais selecionadas
Argumento desenvolvedor3 (a favor): concordo, mas no devemos usar muita hierarquia de menu.
em situaes em que precisamos usar interaes por voz e visual o usurio pode
Exemplo de DR capturado durante o preenchimento
78
checklist permitia a coleta de DR, mas em um projeto
prximo captulo. Nele, o projetista insere e categoriza o DR no momento do projeto de um
de acordo com os princpios para o desenvolvimento de interfaces, uma
concordo com o desenvolvedor2, a interao por voz dem
que tal usar as opes mais selecionadas
concordo, mas no devemos usar muita hierarquia de menu.
permitia a coleta de DR, mas em um projeto
futuro a recuperao desse DR poderia ser prejudicada, pois ele no estava estruturado.
riza o DR no momento do projeto de um
interao e prejudicando a organizao na
o desenvolvedor2, a interao por voz dem
que tal usar as opes mais selecionadas no prompt
2 e no possuir muita hierarquia. os itens devem ser divididos em grupos com nomes intuitivos
ces Multimodais
, pois ele no estava estruturado.
o desenvolvedor2, a interao por voz dem
prompt e deixar todas as opes na
divididos em grupos com nomes intuitivos
Exemplo de DR capturado durante o preenchimento da checklist
2 itens de menu recomendada para interfaces grficas, e isso pode ocasionar em prompt
o desenvolvedor2, a interao por voz demanda menus
e deixar todas as opes na
da checklist
(MMWA)
prompts
anda menus
e deixar todas as opes na
informar em qual sub menu o usurio est. Os itens de menu podem ser falados, caso o usurio esteja usando a
79
4.9 Uma comparao com as abordagens pesquisadas
As abordagens citadas na Seo 3.4.1 so utilizadas para resolver problemas pontuais
no que se refere a transformaes de interfaces multimodais para diferentes dispositivos,
conceito este complementar ao trabalho apresentado nesta tese. No entanto, elas pouco
consideram princpios, guidelines, DR ou padres de projeto para melhorar a usabilidade e
facilitar o trabalho da equipe de projeto de interfaces multimodais Web.
J os frameworks citados na Seo 3.4.2 apiam o desenvolvimento organizado de
aplicaes multimodais e abordam conceitos mais prximos dos problemas que o usurio
enfrenta interagindo com tais aplicaes, como as propriedades CARE utilizadas neste
trabalho para a identificao de problemas de usabilidade e o Gerenciador da Interao, que
apresenta ideias interessantes para a criao de estratgias de tratamento de erros e
confirmao de entradas do usurio, amplamente utilizadas nesta pesquisa, como ser
apresentado mais adiante.
Alm disso, as linguagens de marcao citadas na Seo 3.3, como o X+V, o SALT e
o EMMA possibilitam o desenvolvimento de interfaces Web e aplicaes multimodais de
forma semelhante ao desenvolvimento Web tradicional, facilitando o trabalho dos
desenvolvedores.
Esses dados pesquisados foram utilizados durante o desenvolvimento do projeto de
doutorado, com o objetivo de servir como uma lista de requisitos que foi verificada em cada
ciclo de atividades.
Neste captulo foram descritas as atividades que compem a MMWA e as tcnicas
utilizadas nessas atividades, com alguns exemplos dos estudos de caso realizados neste
trabalho e que sero detalhados no Captulo 6.
Como resultados, que sero apresentados detalhadamente no Captulo 7, a abordagem
otimiza a metodologia de desenvolvimento de interfaces multimodais e habilita a
identificao, a anlise e a descoberta de solues para problemas de usabilidade recorrentes
nesse contexto de interao multimodal.
No prximo captulo ser apresentado o ambiente de autoria que implementa as
atividades definidas na MMWA, visando ajudar os projetistas, desenvolvedores e testadores
de interfaces multimodais em suas tarefas.
80
Captulo 5 - Ambiente de autoria para o projeto de interfaces multimodais Web (MMWA-ae)
81
Captulo 5. Ambiente de autoria para o
projeto de interfaces multimodais Web
(MMWA-ae)
O desenvolvimento de interfaces multimodais uma tarefa difcil para os projetistas e
desenvolvedores e nesta pesquisa percebeu-se que ainda faltam ferramentas que auxiliem no
projeto da interao e permitam avaliar a usabilidade das interfaces durante as fases iniciais
do projeto, possibilitando que elas sejam modificadas medida que os problemas de
usabilidade so encontrados.
Esse contexto apresentou-se como uma excelente oportunidade para explorar
ferramentas que permitem a captura e o armazenamento das experincias e do conhecimento
investidos em projeto, de forma que as solues propostas para resolver os problemas de
projeto em um artefato possam ser reusadas no projeto de outros artefatos.
O ambiente de autoria para o projeto de interfaces multimodais Web, mais conhecido
como MultiModal Web Approach Authoring Environment (MMWA-ae), foi desenvolvido
para automatizar as atividades da MMWA e servir como um framework de projeto,
desenvolvimento e testes de interfaces multimodais Web com o uso das modalidades grfica
e voz.
Este captulo est organizado da seguinte maneira: na Seo 5.2 apresenta-se a
arquitetura de implementao do ambiente de autoria. Na Seo 5.3 apresenta-se a arquitetura
de integrao das interfaces, mdulos e base de dados da ferramenta desenvolvida. Na Seo
5.4 so discutidas as consideraes sobre desenvolvimento baseado em modelos, usando o
MMWA-ae. Na Seo 5.5 so apresentadas as vantagens da utilizao do MMWA-ae em
projetos multimodais Web. Na Seo 5.6 so descritas as limitaes do MMWA-ae.
Finalmente, na Seo 5.7, so apresentadas as consideraes finais deste captulo.
5.2 Arquitetura de implementao do ambiente de autoria
O MMWA-ae um sistema Web projetado na arquitetura cliente-servidor utilizando o
padro de projeto Model-View-Controler (BUSCHMANN; HENNEY; SCHMIDT, 2007).
Captulo 5 Captulo 5 - Ambiente de autoria Ambiente de autoria
Figura
Ambiente de autoria para o projeto
Figura 25 - MMWA
82
MMWA-ae: rea de Projeto
interfaces multimodais
ae: rea de Projeto
ae: rea de Projeto
interfaces multimodais Web (MMWA (MMWA-ae)
83
A arquitetura do MMWA-ae foi planejada com o objetivo de facilitar a separao
entre os dois tipos de interfaces do usurio existentes nessa ferramenta (as interfaces de
projeto e de testes de usabilidade) e a lgica da aplicao, bem como maximizar a
manutenibilidade e a flexibilidade do cdigo, permitindo que outros desenvolvedores possam
estender suas funcionalidades e utilizar os mdulos existentes em outros ambientes. O
ambiente de autoria foi desenvolvido na linguagem Java
2
utilizando-se o ambiente de
desenvolvimento Eclipse 3.4.2
3
. A interface principal da rea de trabalho de projeto do
MMWA-ae apresentada na Figura 25.
Na implementao da camada Viso foram utilizadas as linguagens de programao
JSP, ECMAScript
4
e XHTML
5
, no caso da interface com o projetista. Para a implementao
da interface para realizao de testes com usurios foram utilizadas as linguagens de
programao JSP, ECMAScript, JSGF
6
e XHTML+Voice. No lado do servidor (Modelo e
Controlador) foram utilizados a linguagem de programao Java e o sistema gerenciador de
base de dados MySQL
7
.
A camada do Controlador, funcionando como um intermedirio entre o Modelo e a
Viso, consiste no cdigo responsvel por encaminhar cada solicitao ao mdulo adequado
do modelo para processamento. O resultado encaminhado pelo Controlador ao componente
da Viso.
A camada do Modelo possui os componentes responsveis por processar as
solicitaes encaminhadas pelo Controlador no Mdulo especfico e fornecer acesso aos
dados do Modelo de Domnio que esto armazenados nas bases de dados representadas na
Figura 26.
Toda a apresentao interna do modelo de tarefas foi feita utilizando XML
(Extensible Markup Language) (W3C, 1996) de forma a definir uma forma padronizada para
a adio de marcaes a documentos contendo informao estruturada e a API JDOM
(JDOM, 2009) foi utilizada para transformao, criao, manipulao, e serializao de
documentos XML de entrada que representa um esquema conceitual do modelo de tarefas do
MMWA-ae.
2
http://java.sun.com/
3
http://www.eclipse.org/
4
http://www.ecmascript.org/
5
http://www.w3.org/TR/xhtml1/
6
http://java.sun.com/products/java-media/speech/forDevelopers/JSGF/
7
http://www.mysql.com/
84
A utilizao do JDOM permite simplificar a manipulao em Java de documentos
XML, de forma mais amigvel e abrangente do que o SAX
8
, que no oferece uma forma
padro de escrever um documento XML, e do que o DOM, que pode manipular documentos
XML, mas no permite sua anlise gramatical.
Para a integrao de design rationale com o sistema Wiki foi escolhida a DokuWiki
9
pela sua simplicidade, facilidade de uso, estruturao de pginas hierrquicas (namespaces) e
por implementar a interface Wiki RPC Interface (WIKIRPCINTERFACE, 2010) para a
manipulao de funcionalidades da Wiki.
Para a implementao do cdigo cliente para a comunicao com a DokuWiki foi
utilizado o Apache XML-RPC
10
que uma implementao do XML-RPC em Java, para que
seja usado XML sobre o HTTP para implementar as chamadas remotas RPC (Remote
Procedure Call).
5.3 Arquitetura de integrao das interfaces, mdulos e base de dados
Uma viso geral da arquitetura do ambiente de autoria apresentada na Figura 26.
Figura 26 - MMWA-ae: Arquitetura
Como pode ser observado na Figura 26, a arquitetura do MMWA-ae foi projetada de
forma a disponibilizar duas interfaces equipe de projeto, descritas a seguir:
" A Interface de Projeto (Design Interface) pode ser acessada pelos projetistas
utilizando qualquer navegador Web. O objetivo propiciar a criao de um
8
http://www.saxproject.org/
9
http://www.dokuwiki.org/dokuwiki
10
http://ws.apache.org/xmlrpc/
85
projeto multimodal e trabalhar com as atividades da MMWA de uma forma
controlada e assistida.
" A Interface de Testes (Test Interface) disponibilizada aos projetistas para a
execuo de testes de usabilidade. O objetivo facilitar a execuo de testes com
usurios remotos. O projetista disponibiliza o prottipo executvel da interface
multimodal e o usurio acessa esse prottipo via Web. Tanto o ambiente de
autoria como o prottipo de interface multimodal gerado por ele podem ser
executados em um mesmo servidor de aplicao.
A seguir sero apresentados os principais mdulos que se comunicam com as duas
interfaces disponibilizadas.
5.3.1 Mdulo de Gerenciamento de Projetos
A atividade de projeto gerenciada pelo Mdulo de Gerenciamento de Projetos
(Project Management Module) que utilizado pelo projetista para criar, remover e alterar um
projeto no ambiente de autoria. Portanto, esse mdulo o ponto de comunicao entre a
Interface de Projeto e os outros mdulos do MMWA-ae. Ele prov os mecanismos
necessrios para especificar e gerenciar o dilogo e para projetar interfaces usando o
conhecimento armazenado na MMWA na forma de DR.
5.3.2 Mdulo Gerenciador de Anlise de Tarefas
Com o auxlio do Mdulo Gerenciador de Anlise de Tarefas (Task Analysis
Management Module), o projetista cria a interao multimodal de acordo com o que
especificam as atividades de Identificao (IT) e Representao de Tarefas (RT) da MMWA.
possvel criar, remover e alterar as tarefas, bem como organiz-las nos nveis
abstrato e concreto, escolher uma ou vrias modalidades e usar padres de projeto,
componentes e DR para resolver questes de projeto, alm de obter o raciocnio para resolver
problemas recorrentes com o auxlio das solues usadas em projetos anteriores no mesmo
contexto.
Como foi apresentado no captulo anterior, as tarefas abstratas podem ser classificadas
em: Seleo, Navegao, Deciso, Agrupamento, Controle, Entrada ou Sada. De acordo com
a escolha do projetista, as tarefas concretas so dinamicamente disponibilizadas na interface
do ambiente de autoria de forma que o projetista possa escolher a que melhor se aplica para
seu projeto.
86
No exemplo ilustrado na Figura 25, o projetista criou uma tarefa cujo nome
SelectCCType e escolheu o tipo Selection (Seleo) como sua representao abstrata. O
MMWA-ae apresentou dinamicamente as possveis tarefas concretas disponveis e
relacionadas com o tipo Seleo e o projetista escolheu Credit Card Type (Tipo de
Carto de Crdito), que implementa um componente com as funcionalidades de um dilogo
multimodal (prompts, aes e opes) para obter o tipo de carto de crdito. O projetista
tambm poderia ter selecionado um padro de projeto multimodal, por exemplo, Small
Group Selection ou Large Group Selection, mas neste caso ele precisaria especificar os
itens da interface que no so criados automaticamente, como os prompts, as opes e as
aes.
Alguns padres de projeto, que so independentes da tarefa abstrata como o
Modality Synchronization (Apndice A), so implementados e aplicados instantaneamente,
sem a interferncia do projetista de forma que quando o usurio cria uma tarefa multimodal
os elementos de sincronizao e os eventos correspondentes so automaticamente
apresentados na viso de Aes da rea de trabalho (Task Actions) do MMWA-ae, conforme
ilustrado na Figura 25.
5.3.3 Mdulo Gerenciador de Modalidades
O Mdulo Gerenciador de Modalidades responsvel por selecionar e apresentar na
interface do MMWA-ae as caractersticas inerentes a cada modalidade.
Por exemplo, quando o projetista seleciona que a interface deve permitir comandos de
voz, o Mdulo Gerenciador de Modalidades carrega as informaes pertinentes a esse tipo de
interface e disponibiliza a opo de criar prompts, bem como mecanismos automticos que
sincronizam as interfaces grfica e de voz de acordo com o retorno das gramticas e
informaes relacionadas com as propriedades CARE.
A seguir so elencados os elementos (widgets) implementados no modelo de tarefas e
que podem ser utilizados na especificao das interfaces multimodais como representao
concreta, bem como o exemplo de sua utilizao em interfaces grficas (GUI) e de voz (VUI)
e as propriedades CARE que podem ser escolhidas na fase de projeto:
" Label: define um nome para um elemento de Entrada de informaes.
o GUI: sistema permite ao usurio clicar no label para selecionar uma opo.
o VUI: label usado como componente da gramtica da interface de voz e lido
no prompt inicial.
87
o Multimodal: usurio diz o nome do label, sistema sincroniza com a interface
grfica e opo selecionada.
" C: no ocorre
" A: (GUI) sistema s permite clicar no label, ou seja a interface de
voz desabilitada e o sistema no l o nome da opo. (VUI)
sistema s permite falar a opo desejada.
" R: Label clicado em uma interface grfica e falado em uma
interface de voz.
" E: Ler a opo ou ouvi-la e selecionar a opo falando o seu nome
ou selecionando o label com o mouse.
" Caixa de Texto: usada para obter informaes de entrada de usurios, que variam
em um amplo espectro. Exemplo informar um nome.
o GUI: usurio escreve seu nome.
o VUI: usurio fala seu nome.
o Multimodal: usurio fala seu nome e escreve seu sobrenome.
" C: usurio fala o nome e escreve o sobrenome
" A: no permitir ao sistema ler o nome do usurio.
" R: nome escrito e falado.
" E: falar ou digitar o nome.
" Combo Box: utilizado para representaes abstratas do tipo seleo. Habilita a
seleo de uma ou vrias opes conhecidas de antemo pelo usurio.
o GUI: usurio usa mecanismos convencionais para selecionar a opo, por
exemplo, clicando na caixa, expandindo a lista e utilizando a barra de rolagem.
o VUI: sistema toca prompt inicial solicitando a entrada do usurio. Sistema l
as opes escondidas somente se o usurio tiver dificuldades de interagir (por
exemplo, na ocorrncia de um erro na interface de voz).
o Multimodal: usurio usa a barra de rolagem, sistema l as opes, usurio fala
a opo desejada, sistema seleciona a opo e pergunta se usurio deseja
selecionar outra opo.
88
" C: ocorre quando usurio deseja selecionar mltiplas opes.
Usurio seleciona uma opo e sistema fornece a alternativa de
selecionar outra opo. Usurio usa a interface grfica para
selecionar a segunda opo.
" A: no permitir ao usurio clicar ou falar.
" R: clicar na opo e falar ao mesmo tempo.
" E: clicar na opo ou falar a opo em tempos diferentes.
" List Box: permite ao usurio selecionar um ou mais itens de uma lista contida
dentro de uma caixa de texto.
o GUI: usurio usa mecanismos convencionais para selecionar a opo
o VUI: sistema toca prompt inicial solicitando a entrada do usurio. Sistema l
as opes escondidas somente se o usurio tiver dificuldades de interagir (por
exemplo, na ocorrncia de um erro).
o Multimodal: usurio usa a barra de rolagem, sistema l as opes, usurio fala
a opo desejada, sistema seleciona a opo e pergunta se usurio deseja
selecionar outra opo.
" C: ocorre quando usurio deseja selecionar mltiplas opes.
Usurio seleciona uma opo e sistema fornece a alternativa de
selecionar outra opo. Usurio usa a interface grfica para
selecionar a segunda opo.
" Radio Button: um elemento de mltipla escolha (seleo), mas permite ao
usurio escolher apenas uma opo.
o VUI: sistema toca prompt inicial solicitando a entrada do usurio. Usurio diz
a opo desejada.
89
o Multimodal: usurio diz a opo e sistema marca o item correspondente na
interface grfica.
" C: no ocorre.
" Check Box: um elemento de mltipla escolha (seleo), mas permite ao usurio
escolher vrias opes.
o VUI: sistema toca prompt inicial solicitando a entrada do usurio. Usurio diz
a(s) opo(es) desejada(s).
o Multimodal: usurio diz a opo e sistema marca o item correspondente na
interface grfica.
" C: no ocorre.
" Button: um elemento de controle que permite executar aes tais como limpar
ou submeter dados de um formulrio.
o GUI: usurio usa mecanismos convencionais para pressionar o boto
o VUI: gramtica de universais inclui a opo do boto que pode ser
mencionada pelo usurio. Geralmente utilizado um prompt de confirmao no
final da interao para confirmar todos os dados antes de prosseguir para uma
prxima pgina.
o Multimodal: usurio ouve um prompt de confirmao e pressiona o boto
confirmando suas entradas.
" C: usurio ouve um prompt de confirmao e pressiona o boto
confirmando suas entradas.
90
" A: no permitir ao usurio clicar no boto ou falar a ao
correspondente.
" Link: um elemento de Navegao que permite dar continuidade no fluxo de um
conjunto de tarefas.
o GUI: usurio usa mecanismos convencionais para clicar no link.
o VUI: gramtica global inclui as opes com todos os links de uma pgina que
podem ser mencionados pelo usurio.
o Multimodal: usurio diz o nome do link e sistema executa a ao
correspondente.
" C: usurio visualiza o link e decide mudar de pgina ou executar
outra tarefa e diz a opo desejada.
" A: no permitir ao usurio clicar no link ou falar o item
correspondente.
" R: clicar no link e falar ao mesmo tempo.
" E: clicar no link ou falar a opo em tempos diferentes.
" Coordenada X,Y: um elemento de Navegao, mais utilizado quando h a
possibilidade de se usar dispositivos que permitem toque.
" Formulrio: um elemento de Agrupamento utilizado para armazenar dados de
uma tarefa.
" Menu: um elemento de Seleo com Navegao utilizado para resumir as
funcionalidades de um site em um local conhecido pelo usurio.
" Gramtica: uma gramtica dirigida pode ser construda com base no nome e
descrio de uma tarefa, bem como utilizando as opes e aes e dados obtidos
na 1 atividade da abordagem. Gramticas estatsticas podem ser desenvolvidas
quando h a necessidade de projetar dilogos com pergunta aberta.
" Prompts: so mensagens de Sada apresentadas aos usurios em forma de arquivo
de udio ou texto sintetizado (Text To Speech - TTS), utilizadas em interfaces de
91
voz. O TTS mais simples de manter e modificar e pode ser utilizado durante o
desenvolvimento do software e nos casos onde ainda no se sabe o que ser dito
de antemo. J os udios gravados so mais usados quando o software est sendo
utilizado por usurios, pois so udios com maior qualidade e apresentam
pronncia natural.
5.3.4 Mdulo Gerenciador de Dilogo
O Mdulo Gerenciador do Dialogo responsvel por armazenar informaes relativas
ao fluxo da aplicao e garantir que: todos estados so alcanados, no h estados rfos e
no h problemas de navegao.
Esse mdulo tambm se comunica com a base de dados de log e extrai informaes
sobre interaes do usurio com as interfaces projetadas. Dessa forma, possvel verificar se
existem problemas de interao com um determinado componente da interface e sugerir
alteraes diretamente na rea de trabalho do MMWA-ae.
De acordo com a especificao da MMWA, durante todo o processo de projeto deve
ser possvel coletar e armazenar DR, para que futuros projetos se beneficiem das decises
tomadas e do raciocnio correspondente s solues implementadas. No entanto, a criao e a
utilizao de DR pode ser demorada, incmoda e gerar custos excessivos (DE LUCIA et al.,
2009). Para resolver esta limitao o ambiente de autoria permite ao projetista extrair e
capturar DR quando for necessrio.
O MMWA-ae possui um mecanismo abstrato para capturar e armazenar DR
permitindo que as organizaes e os desenvolvedores utilizem as principais caractersticas de
qualquer sistema Wiki para colaborar na especificao, execuo de tarefas e durante as
atividades de testes.
Isso possvel com a implementao da interface WIKI XML-RPC 2.0 (Figura 26)
que usada para conectar a rea de trabalho do MMWA-ae com qualquer sistema Wiki que
implemente essa interface, de forma que o DR pode ser armazenado e recuperado por meio
da criao e gerenciamento de pginas Wiki estruturadas.
Na Figura 27 demonstrada a interao entre o MMWA-ae e a DokuWiki. O
projetista, neste exemplo, insere um argumento para uma posio que est relacionada a
uma questo. Esta questo, por sua vez, est relacionada a uma tarefa concreta. Como
pode-se observar, a pgina da DokuWiki carregada dentro do MMWA-ae, mas esta pgina
pode tambm ser acessada diretamente pela URL da Wiki.
Captulo 5
concatenado com o nome da tarefa (
sendo alvo de discusso (
aba Design Rationale
facilita a busca por solues relacionadas a um tipo de artefato, por exemplo, pode
por todos os DR relacionados com tarefas concretas. O DR completo registrado no exemplo
desta tarefa pode ser lido no
DokuWiki utilizando chamadas remotas (RPC), de forma a organizar todo o DR inerente ao
projeto da interao multimodal com o auxlio de
so estruturadas e relacionadas.
criados, a ferramenta organiza o contedo na Wiki e os exibe de maneira estruturada,
permitindo que o projetista t
projetando no momento em que a dvida aparece, facilitando a busca por uma soluo j
utilizada previamente.
Captulo 5 - Ambiente de autoria
O ttulo da pgina (
sendo alvo de discusso (
Essa particularidade facilita a busca por determinados tipos de DR. Acessando
Design Rationale
arefa pode ser lido no
O ambiente de autoria MMWA
Posteriormente, medida que
Figura
Ambiente de autoria
O ttulo da pgina (
sendo alvo de discusso (concrete
Design Rationale do MMWA
arefa pode ser lido no Apndice C
Posteriormente, medida que
Figura 27 - Captura de DR usando o MMWA
O ttulo da pgina (p1_getcartype_concrete
concatenado com o nome da tarefa (getcartype
concrete).
do MMWA-ae existe a possibilidade de filtrar o DR por tipo. Isso
Apndice C.
Posteriormente, medida que questes, respostas, argumentos e solues
permitindo que o projetista tenha acesso informao especfica atividade que ele est
Captura de DR usando o MMWA
92
p1_getcartype_concrete
getcartype) concatenado com o tipo de artefato que est
ae existe a possibilidade de filtrar o DR por tipo. Isso
.
O ambiente de autoria MMWA-ae estabelece um canal de comunicao com a
projeto da interao multimodal com o auxlio de templates
questes, respostas, argumentos e solues
enha acesso informao especfica atividade que ele est
Captura de DR usando o MMWA
p1_getcartype_concrete) contm o nome do projeto (p1)
) concatenado com o tipo de artefato que est
ae estabelece um canal de comunicao com a
templates, ou
Captura de DR usando o MMWA-ae e a DokuWiki
) contm o nome do projeto (p1)
seja, pginas predefinidas que
ae e a DokuWiki
interfaces multimodais Web (MMWA
facilita a busca por solues relacionadas a um tipo de artefato, por exemplo, pode-se buscar
ae e a DokuWiki
(MMWA-ae)
Essa particularidade facilita a busca por determinados tipos de DR. Acessando-se a
se buscar
questes, respostas, argumentos e solues so
Captulo 5
projetos se beneficiem com buscas de DR eficientes assegurando que resultados precisos
sejam obtidos. Essa organizao de conhecimento/raciocnio visa facilitar a identificao de
padres de projeto,
especficas da MMWA em diferentes contextos de aplicao.
5.3.5
rpidos de interfaces multimodais para serem alvo de avaliaes de usabilidade. Essa
funcionalidade utiliza o
Evaluation Management Module
da aplicao (
Cdigo
Base de
usabilidade
que contm elementos de interface grfica
entre elas
Esse mecanismo tambm
padres de projeto,
Mdulo de Gerenciamento de Avaliao de Usabilidade
Outra caracterstica importante do MMWA
funcionalidade utiliza o
Este mdulo responsvel por reunir
da aplicao (Application Database
(Code Generator Database
de Dados de
usabilidade.
Para cada tarefa especificada pelo projetista, a ferramenta cria um trecho de cdigo
elas (Figura 30
Figura 28
Ambiente de autoria
Esse mecanismo tambm
padres de projeto, tendo em vista que a busca por contedos se relaciona a atividades
funcionalidade utiliza o Mdulo de Gerenciamento de Avaliao de Usabilidade
Application Database
Code Generator Database
log (LOG Data
30) e inclui funes para capturar eventos de
28 - Trecho de cdigo de interface de voz gerado pelo MMWA
Esse mecanismo tambm permite a organizao da informao de forma que futuros
tendo em vista que a busca por contedos se relaciona a atividades
Evaluation Management Module) (Figura
Application Database), gerar o cdigo do aplicativo usando o Gera
Code Generator Database) e incluir as funes para capturar os
Database), alm de permitir a criao do protocolo de testes
e inclui funes para capturar eventos de
Trecho de cdigo de interface de voz gerado pelo MMWA
93
permite a organizao da informao de forma que futuros
Outra caracterstica importante do MMWA-
Figura 26).
Este mdulo responsvel por reunir toda a informao de dilogo do banco de dados
), gerar o cdigo do aplicativo usando o Gera
) e incluir as funes para capturar os
, alm de permitir a criao do protocolo de testes
que contm elementos de interface grfica (Figura 29
-ae a possibilidade de gerar prottip
toda a informao de dilogo do banco de dados
) e incluir as funes para capturar os
29) e de voz
ae a possibilidade de gerar prottip
) e incluir as funes para capturar os logs
e de voz (Figura 28
interao (Figura
ae a possibilidade de gerar prottip
Mdulo de Gerenciamento de Avaliao de Usabilidade (Usability
logs de interao na
28), a sincronizao
Figura 31).
Trecho de cdigo de interface de voz gerado pelo MMWA-ae
(MMWA-ae)
ae a possibilidade de gerar prottipos
Usability
), gerar o cdigo do aplicativo usando o Gerador de
de interao na
, alm de permitir a criao do protocolo de testes de
, a sincronizao
Captulo 5
hospeda a MMWA
usabilidade da interface projetada na busca por problemas que possam ser corrigidos antes da
entrega de uma verso final ao cliente.
determinado tipo de interface, por meio de anlise de tabelas e grficos
MMWA
tambm as principais limitaes dos
recrutamento de usurios, disponibilidade de tempo e recursos para realizar os testes, j que
todo o processo feito remotamente.
tarefa Choose Service
possvel observar
Figura 29
Figura 30
Figura
Disponibilizando
hospeda a MMWA
Essa funcionalidade possibilita
MMWA-ae, bem como erros de projeto ou pontos de melhorias de usabilidade. Supre
Na Figura
Choose Service
possvel observar que a tarefa completada mais rapidamente utilizando a interface de voz.
Ambiente de autoria
29 - Trecho de cdigo de interface grfica gerado pelo MMWA
30 - Trecho de cdigo de sincronizao gerado pelo MMWA
Figura 31 -
Disponibilizando-se essa interface em um ambiente
hospeda a MMWA-ae, possvel realizar testes remotos com us
Essa funcionalidade possibilita
, bem como erros de projeto ou pontos de melhorias de usabilidade. Supre
32, apresentado o grfico que mostra o tempo mdio de interao na
Choose Service (Escolher Servio
que a tarefa completada mais rapidamente utilizando a interface de voz.
Trecho de cdigo de interface grfica gerado pelo MMWA
Trecho de cdigo de sincronizao gerado pelo MMWA
Trecho da funo que captura eventos de erro
se essa interface em um ambiente
ae, possvel realizar testes remotos com us
Essa funcionalidade possibilita tambm
, apresentado o grfico que mostra o tempo mdio de interao na
Escolher Servio
94
se essa interface em um ambiente
tambm a identificao de padres de interao com
testes com usurios
Escolher Servio) nas interfaces grfica (
se essa interface em um ambiente Web
a identificao de padres de interao com
m usurios
) nas interfaces grfica (
Web, que pode ser o mesmo que
ae, possvel realizar testes remotos com usurios, avaliando
m usurios que so a dificuldade de
) nas interfaces grfica (GUI) e
Trecho de cdigo de interface grfica gerado pelo MMWA-ae
Trecho de cdigo de sincronizao gerado pelo MMWA-ae
, que pode ser o mesmo que
urios, avaliando-se assim a
determinado tipo de interface, por meio de anlise de tabelas e grficos gerados pelo
que so a dificuldade de
e de voz (VUI
(MMWA-ae)
, que pode ser o mesmo que
se assim a
gerados pelo
que so a dificuldade de
VUI).
Captulo 5
Figura
mencionados na MMWA
testes explicando a proposta da avaliao de usabilidade (
das tarefas
satisfao de uso
Figura 32 -
Esse mecanismo de testes com usurios remotos requer
mencionados na MMWA
efas ou cenrio de uso a serem executado
satisfao de uso; a
Ambiente de autoria
Tempo mdio de interao na tarefa
mecanismo de testes com usurios remotos requer
mencionados na MMWA, durante a execuo do MMLOG
ou cenrio de uso a serem executado
; a existncia de um canal direto com os realizadores dos testes,
Figura 33
empo mdio de interao na tarefa
, durante a execuo do MMLOG
ou cenrio de uso a serem executado
existncia de um canal direto com os realizadores dos testes,
33 - MMLOG: Criao do protocolo de testes
95
empo mdio de interao na tarefa
, durante a execuo do MMLOG
ou cenrio de uso a serem executados (Figura
MMLOG: Criao do protocolo de testes
empo mdio de interao na tarefa ChooseService
, durante a execuo do MMLOG, como
testes explicando a proposta da avaliao de usabilidade (Figura
Figura 35); a criao
ChooseService para GUI e VUI
mecanismo de testes com usurios remotos requer alguns cuidados que so
, como: a criao
Figura 33 e Figura
); a criao de
para GUI e VUI
alguns cuidados que so
criao do protocolo de
Figura 34) e a descrio
um questionrio de
existncia de um canal direto com os realizadores dos testes, entre outros
(MMWA-ae)
para GUI e VUI
alguns cuidados que so
do protocolo de
) e a descrio
questionrio de
entre outros.
Captulo 5
durante a criao de cada uma das tarefas, o projetista auxiliado por um
principais tarefas so: realizar a anlise de solues, obter os principais
usabilidade para serem usados na gerao do cdigo, garantir que os
checklist
5.4
o MMWA
Por fim, a MMWA
checklist disponvel na MMWA sejam considerados na gerao do prottip
Desenvolvimento de interfaces multimodais orientado a modelos
MMWA-ae
Ambiente de autoria
Figura
Figura
Por fim, a MMWA-ae tambm viabiliza a criao da
disponvel na MMWA sejam considerados na gerao do prottip
Figura 34 - Protocolo de testes em execuo
35 - Cenrio de uso criado
ae tambm viabiliza a criao da
96
Protocolo de testes em execuo
Cenrio de uso criado
ae tambm viabiliza a criao da
Cenrio de uso criado pelo MMLOG
ae tambm viabiliza a criao da documentao de projeto
pelo MMLOG
documentao de projeto
usabilidade para serem usados na gerao do cdigo, garantir que os itens
documentao de projeto
durante a criao de cada uma das tarefas, o projetista auxiliado por um wizard
principais tarefas so: realizar a anlise de solues, obter os principais princpios
itens que compem a
disponvel na MMWA sejam considerados na gerao do prottipo.
(MMWA-ae)
documentao de projeto, pois
wizard, cujas
princpios de
que compem a
Desenvolvimento de interfaces multimodais orientado a modelos com
97
Modelos so frequentemente usados no projeto e avaliao de sistemas interativos
para ajudar na identificao e no entendimento de aspectos complexos do artefato que est
sendo projetado (PATERN, 2005). As abordagens baseadas em modelos fornecem uma
descrio estruturada da informao disponvel em aplicaes multimodais de forma que
ambientes inteligentes possam apresentar tal informao de acordo com o contexto de uso,
podendo torn-las ubquas e pervasivas.
A obteno de informaes sobre o uso das modalidades e a extrao de
recomendaes para melhorar o projeto das interfaces multimodais geralmente uma tarefa
complexa, pois o nmero de modalidades utilizadas pode ser grande, as ferramentas e
linguagens de programao existentes so complexas e no fornecem esse tipo de suporte.
Nessa perspectiva, os mtodos de modelagem tm sido utilizados para verificar a
especificao dos sistemas, prever problemas de usabilidade, como os estados no
alcanados, detectar conflitos de modalidades e sugerir eventos necessrios para fuso e
fisso de modalidades. Dessa forma, o projetista pode concentrar-se nos aspectos
semnticos do projeto ao invs de preocupar-se com detalhes de implementao,
plataforma, ferramentas, entre outros.
Patern e Santos (2007) propuseram combinar a anlise de tarefas realizada no
Concurrent Task Trees Model com gravaes em vdeo e a captura do movimento dos olhos
(eye tracking) para melhor entender a interao.
Chang e Bourguet (2008) usam tcnicas de especificao formal em combinao com
os mtodos tradicionais de avaliao de usabilidade para realizar uma verificao detalhada e
a anlise de usabilidade dos problemas relacionados aos eventos necessrios para a fuso e
fisso de modalidades.
O ambiente de autoria MMWA-ae tem como base um modelo cujo conceito central
a anlise de tarefas. Para cada tarefa possvel armazenar informaes sobre as escolhas do
projetista com relao a: interfaces concretas e abstratas, modalidades, prompts, aes,
opes, avaliao heurstica e testes com usurios. A proposta da utilizao do modelo de
tarefas na fase de projeto descrever as relaes semnticas e temporais entre as tarefas
identificadas.
J na fase de testes, o mecanismo de avaliao de usabilidade definido na MMWA
gera informaes que so guardadas nesse modelo e em conjunto com o design rationale
uma fonte importante de sugestes para modificaes das interfaces antes da finalizao e
entrega do produto final.
98
Cada tarefa no modelo da MMWA composta por oito elementos, mais
precisamente:
1. Tarefa Abstrata (Abstract Task): representa a atividade de Identificao de
Tarefas (IT) da MMWA;
2. Tarefa Concreta (Concrete Task): representa a atividade de Representao de
Tarefas (RT) da MMWA;
3. Modalidade (Modality): representa a escolha de uma ou mais modalidades para
serem usadas em uma tarefa, bem como as propriedades CARE correspondentes;
4. Prompts: representam as mensagens utilizadas para obter entrada do usurio em
interfaces de voz, definidos na atividade de Anlise de Solues da MMWA;
5. Opes (Options): so utilizadas para definir a continuidade do dilogo
fundamentado em decises tomadas dentro de uma tarefa especfica, definidos na
atividade de Anlise de Solues da MMWA;
6. Aes (Actions): so definidas na atividade de Anlise de Solues da MMWA;
7. Dados obtidos com o mecanismo de avaliao heurstica (MMHE): relativos
avaliao heurstica, definidos na atividade de Avaliao de Usabilidade da
MMWA;
8. Dados obtidos com o mecanismo de anlise de logs (MMLOG): relativos aos
logs que mostram a interao de usurios com as interfaces geradas, executando
as tarefas definidas no protocolo dos Testes com Usurios, definidos na atividade
de Avaliao de Usabilidade da MMWA.
Para ilustrar, os DR apresentados na Figura 36 esto relacionados com a mesma
tarefa, GetCarType, mas esto presentes em cinco elementos diferentes do modelo:
Prompts, Actions, MMLOG, MMHE e Options. Pelo fato de que os problemas capturados
neste exemplo so genricos, um mesmo problema poderia ter sido extrado de uma outra
aplicao no mesmo contexto, ou seja, de um projeto diferente com funcionalidades
semelhantes.
Por esse motivo, foi desenvolvida uma funcionalidade que permite ao projetista
agrupar todos os DR similares a um determinado componente do modelo de tarefas
considerando todos os projetos existentes no banco de dados, tornando possvel identificar
Captulo 5
padres de projeto
Captulo 7
obter feedback
trabalho de projeto
nos testes com usurios (MMLOG) e o
sugerindo um
Figura
padres de projeto
Captulo 7 desta tese.
Figura 36
Como resultado
feedback de tratamento e correo de erros do modelo de tarefas diretamente na
trabalho de projeto
Na Figura
sugerindo um padro de projeto
37 - Sugesto automtica de padro de projeto multimodal para corrigir um problema
Ambiente de autoria
padres de projeto de uma maneira mais s
desta tese.
- Elementos do Modelo de Tarefas da MMWA e o DR
Como resultado, foi criado
de tratamento e correo de erros do modelo de tarefas diretamente na
trabalho de projeto do ambiente de autoria
37 pode-se observar
padro de projeto
Sugesto automtica de padro de projeto multimodal para corrigir um problema
de uma maneira mais s
Elementos do Modelo de Tarefas da MMWA e o DR
criado um mecanismo n
do ambiente de autoria
se observar
padro de projeto para corrigir um potencial problema de usabilidade.
de usabilidade
99
de uma maneira mais simplificada, como ser explicado mais adiante n
um mecanismo n
do ambiente de autoria, por meio dos dados obtidos com os
DR coletado e armazenado durante todo o processo
que na tarefa
para corrigir um potencial problema de usabilidade.
de usabilidade
implificada, como ser explicado mais adiante n
um mecanismo no MMWA
, por meio dos dados obtidos com os
coletado e armazenado durante todo o processo
que na tarefa GetCarType
de usabilidade
Elementos do Modelo de Tarefas da MMWA e o DR recuperado
MMWA-ae que permite ao projetista
, por meio dos dados obtidos com os
GetCarType existe uma indicao
recuperado
ae que permite ao projetista
, por meio dos dados obtidos com os logs
existe uma indicao
(MMWA-ae)
implificada, como ser explicado mais adiante no
ae que permite ao projetista
de tratamento e correo de erros do modelo de tarefas diretamente na rea de
gerados
existe uma indicao
100
A identificao automtica de um problema de usabilidade e o feedback fornecido
pelo modelo de tarefas na rea de trabalho onde a tarefa projetada foi possvel com o uso do
MMLOG, nos testes com usurios remotos.
O MMLOG identificou erros do tipo nomatch na interface de voz, conforme pode ser
observado na Figura 38 (linhas 71 e 77), e tentativas posteriores de interao com a interface
grfica correspondente (linha 80) para recuperar o erro ocorrido na interface de voz.
O MMWA-ae reconhece este potencial problema de usabilidade, salva a informao
de sugesto no modelo de tarefas e ento notifica o projetista que uma possvel soluo
utilizar o padro de projeto multimodal Large Group Selection (Figura 37), para organizar o
conjunto de possveis escolhas/valores em uma ou mais tarefas, sincronizar essas tarefas e
informar as possveis opes do menu no prompt inicial, restringindo a fala do usurio.
Figura 38 - Trecho do modelo que mostra dois erros na interface de voz e uma interao
grfica correta
O projetista pode tambm buscar por uma soluo acessando o DR capturado em
outros projetos na viso de Prompts do ambiente de autoria. Assim, caso o projetista opte por
no utilizar o padro de projeto sugerido, ele verifica que uma possvel correo informar
no prompt inicial as possveis opes do menu, limitando a fala do usurio.
101
Com a implementao dessa sugesto os usurios experientes podem usar o
mecanismo de barge-in das interfaces de voz (COHEN; GIANGOLA; BALOGH, 2004) para
interromper a pergunta de sada do sistema, enquanto os novatos fornecem uma resposta mais
restrita aps ouvir toda a lista com as opes do menu.
Os outros problemas identificados nos componentes do modelo, que foram
apresentados na Figura 36 tambm contriburam para essa sugesto de padro de projeto.
Outro exemplo de problema de usabilidade que automaticamente identificado com o
uso das informaes presentes no modelo o uso das propriedades CARE.
No projeto da interface para a criao de rotas entre dois pontos de interesses em um
mapa, do terceiro estudo de caso, que ser discutido no Captulo 6, o projetista escolheu
utilizar multimodalidade com as seguintes propriedades CARE: Redundncia e Equivalncia.
O gerador de cdigo da MMWA-ae implementa a Redundncia de tal forma que caso
o usurio selecione e fale a mesma opo, a interface entender que so comandos
redundantes, e no tentar sincronizar as modalidades duas vezes.
No caso da Equivalncia, o software tomar a mesma deciso, relativa ao fluxo de
informaes, independente da modalidade escolhida pelo usurio para interagir com a
interface.
No entanto, caso o usurio utilize um dispositivo que permita a interao por toque
para apontar para o local e falar Selecione esse, ser necessrio realizar uma fuso do
significado selecionar com a coordenada correspondente ao toque realizado na tela do
dispositivo.
Neste caso, a propriedade Complementaridade foi utilizada, mas como o projetista
no previu o seu uso, a fuso no ser realizada e poder ocorrer uma confuso de
interpretao caso o toque seja realizado antes do processamento da voz, pois no se saber o
que selecionar.
Comparando-se as informaes das linhas 155 a 158 da Figura 39 com a linha 181 da
Figura 40, ou seja, as propriedades selecionadas pelo projetista na MMWA com o resultado
de uma interao de um usurio real possvel sugerir a incluso da propriedade
Complementaridade (C).
Neste exemplo, o erro foi identificado durante os testes com usurios e uma nova
sugesto foi feita pelo modelo de tarefas, como pode ser observado no trecho de cdigo
grifado da Figura 39. A informao ento apresentada na rea de trabalho do MMWA-ae,
ajudando o projetista na realizao de correes da interface multimodal.
102
Figura 39 - Propriedades CARE escolhidas na fase de projeto
Figura 40 - Propriedades CARE utilizadas nos Testes com Usurios
Atualmente, os problemas e solues encontrados no design rationale precisam ser
manualmente includos no modelo. Como trabalho futuro pretende-se incluir um mecanismo
automtico para auxiliar na divulgao e na correo dos problemas encontrados no design
rationale por meio da integrao com o modelo de anlise de tarefas da mesma forma que
feito para os testes com usurios. Essa tarefa difcil, pois requer a interpretao do que foi
concordado como soluo entre os projetistas e a sua representao na linguagem do modelo,
ou seja, em XML.
Outro ponto de destaque o preenchimento do formulrio do MMHE que tambm
fornece informaes importantes ao modelo de tarefas.
Captulo 5
princpios,
relacionado caixa de seleo
visualizar todas as opes sem realizar uma interao de clique
Porm c
ele pode dizer, a ordenao das opes tambm deve ser realizada.
Figura
tipo de erro diretamente na
uma chamada para
iniciada
Figura
Por exemplo, na
princpios, checklists
Em uma interface multimodal com reconhecimento de voz, o usurio no consegue
Porm com a caixa de seleo aberta, o usurio pode compreender todas as expresses que
Figura 41 - Trecho do modelo que permite a identificao de um problema de usabilidade
Existe uma
tipo de erro diretamente na
uma chamada para
iniciada, conforme est destacado na
Figura 42 - MMWA
Ambiente de autoria
Por exemplo, na Figura
checklists, guidelines
uma interface multimodal com reconhecimento de voz, o usurio no consegue
caixa de seleo aberta, o usurio pode compreender todas as expresses que
Trecho do modelo que permite a identificao de um problema de usabilidade
Existe uma lgica no MMWA
tipo de erro diretamente na viso
uma chamada para uma funo
, conforme est destacado na
MMWA-ae sugerindo uma correo,
usabilidade identificado pelo MMHE
Figura 41 possvel observar que por meio do relacionamento entre
guidelines e heursticas o ava
relacionado caixa de seleo.
MMWA-ae que permite ao projetista visualizar que houve esse
viso de Aes
funo JavaScript
, conforme est destacado na Figura
ae sugerindo uma correo,
103
possvel observar que por meio do relacionamento entre
e heursticas o avaliador identificou que existe um problema
ae que permite ao projetista visualizar que houve esse
de Aes (Task Actions
JavaScript que expande a caixa de seleo quando a tarefa
Figura 42.
ae sugerindo uma correo,
liador identificou que existe um problema
Task Actions) do ambiente de autoria
que expande a caixa de seleo quando a tarefa
ae sugerindo uma correo, fundamentado
visualizar todas as opes sem realizar uma interao de clique/toque na interface grfica.
do ambiente de autoria
fundamentado em um problema de
na interface grfica.
do ambiente de autoria e incluir
em um problema de
(MMWA-ae)
na interface grfica.
e incluir
em um problema de
104
5.5 Vantagens da ferramenta
O gerador de cdigo utilizado no MMWA-ae possui componentes de interface de
multimodal que tambm permitem a criao de interfaces de voz convencionais. Os
componentes disponveis so: carto de crdito, data, moeda, nmero de telefone, cidades/
estados americanos e cdigo postal. A utilizao de componentes uma vantagem pois todo
o raciocnio do projeto da interao envolvida no dilogo j est pronto, restando apenas
configurar o componente para uma situao especfica. O MMWA-ae tambm disponibiliza
funes ECMAscript para verificao de dados de entrada, que esto embutidas nos
componentes.
O sincronismo das interfaces um problema recorrente nesta rea de pesquisa e foi
tratado nesta pesquisa com a proposta do padro de projeto Modality Synchronization,
apresentado no Apndice A.
O MMWA-ae tambm pode ser estendido para utilizar novas modalidades, incluir
novas linguagens de programao na base de gerao de cdigo, alm de poder ser utilizado
por outras ferramentas, pois so oferecidas interfaces de projeto, testes e organizao de DR
por meio da interface de comunicao com sistemas Wiki aos desenvolvedores de software.
Por ltimo, o modelo proposto tambm uma vantagem, pois alm de promover a
reutilizao sistemtica e gerencivel de conhecimento de projeto, considera informaes
teis do mecanismo de avaliao de usabilidade, e fornece dicas de correo de problemas
diretamente no ambiente de projeto, facilitando as tarefas da equipe de projeto.
5.6 Limitaes da ferramenta
A personalizao de layouts nas interfaces grficas uma limitao do MMWA-ae. O
projetista precisa editar o cdigo fonte caso queira incluir seus prprios estilos CSS. A
incluso de editores HTML pode melhorar a usabilidade da ferramenta, como foi sugerido
nas entrevistas realizadas com os desenvolvedores.
A busca por DR pode ser melhorada com a criao de campos para permitir filtros
com o objetivo de obter resultados mais expressivos e pontuais para o desenvolvedor.
Novas formas de gravao de DR podem ser includas, por exemplo, gravao de
vdeo ou incluir uma funcionalidade que permita registrar e-mail ou mensagens instantneas
trocadas entre as equipes de projeto diretamente na Wiki (ETO; TAKABAYASHI; MASUI,
2005).
Como trabalho futuro pretende-se incluir no MMWA-ae um mecanismo que permita a
fuso de interfaces grficas previamente existentes com interfaces de voz. O projetista ficaria
105
responsvel por importar a interface grfica no MMWA-ae e esta se encarregaria de obter as
tarefas abstratas, selecionar possveis representaes concretas diferentes das existentes na
interface atual, criar a interface de voz correspondente, sincronizar as interfaces e incluir o
mecanismo de avaliao de usabilidade.
Dessa forma, o projetista despenderia menos esforo na verificao das checklists e da
utilizao das melhores prticas existentes e compiladas na forma de DR durante o processo
de especificao e criao de interfaces multimodais Web.
Neste captulo foram discutidos os conceitos relacionados ao ambiente de autoria
MMWA-ae, tais como a sua arquitetura, seus mdulos e as tecnologias utilizadas, bem como
as suas vantagens e limitaes.
No captulo seguinte sero apresentados os estudos de caso realizados com a
abordagem e o ambiente de autoria propostos nesta tese.
Captulo 6 - Estudos de caso
107
Captulo 6. Estudos de caso
Nos captulos anteriores foram discutidos os conceitos e os trabalhos cientficos que
serviram como base para o desenvolvimento da abordagem e do ambiente de autoria
propostos nesta tese.
Neste captulo so apresentados os estudos de caso realizados para comprovar
algumas hipteses e testar as idias propostas na prtica.
Na Seo 6.2 apresenta-se a metodologia que foi utilizada para o desenvolvimento
deste trabalho. Na Seo 6.3 feita uma descrio rpida dos estudos de caso e nas Sees
6.4, 6.5 e 6.6 so discutidos os seus detalhes. Finalmente, na Seo 6.7, so apresentadas as
consideraes finais deste captulo.
6.2 Metodologia
O desenvolvimento deste trabalho, visando alcanar os objetivos propostos, foi
conduzido, principalmente, por meio de procedimentos de pesquisa bibliogrfica e de estudos
de caso.
A pesquisa bibliogrfica foi realizada desde o incio de 2007 e uma atividade que foi
mantida constante durante o desenvolvimento do doutorado. Conforme recomendado em
(WAZLAWICK, 2009), inicialmente foram pesquisados surveys sobre o assunto com o
objetivo de obter o estado da arte da rea de pesquisa e sua evoluo histrica. Na sequncia,
os trabalhos clssicos e livros foram pesquisados e posteriormente foram pesquisadas fontes
mais recentes sobre o assunto da tese.
Os principais temas de pesquisa que contriburam para este trabalho e foram alvo da
pesquisa bibliogrfica so: interao humano-computador, interao multimodal, interao
por voz, interfaces adaptativas, gerao automtica de interfaces, integrao entre projeto de
interface Web e projeto de interface de voz, acessibilidade no projeto Web sendo alcanada
com o auxlio do projeto da interface de voz, usabilidade e mtodos para avaliao de
usabilidade em sistemas multimodais, design rationale e padres de projeto.
Foram analisados os trabalhos relacionados reportados em livros e nos principais
peridicos e conferncias especializados na rea de interao multimodal disponveis em
bibliotecas digitais da ACM, IEEE, Springer, e outras fontes de artigos cientficos da rea.
108
Aps as etapas de estudos e pesquisa bibliogrfica, foi iniciado o trabalho de estudos
de caso.
O mtodo de estudo de caso um mtodo especfico de pesquisa de campo
qualitativo. Estudos de campo so investigaes de fenmenos medida que ocorrem, sem
qualquer interferncia significativa do pesquisador. Seu objetivo compreender o evento em
estudo e ao mesmo tempo desenvolver teorias mais genricas a respeito dos aspectos
caractersticos do fenmeno observado (FIDEL, 1992).
Segundo (HARTLEY, 1994), o estudo de caso consiste em uma investigao
detalhada de uma ou mais organizaes, ou grupos dentro de uma organizao, com vistas a
prover uma anlise do contexto e dos processos envolvidos no fenmeno em estudo. O
fenmeno no est isolado de seu contexto (como nas pesquisas de laboratrio), j que o
interesse do pesquisador justamente essa relao entre o fenmeno e seu contexto.
Para Trauth et al. (2000) uma das principais caractersticas do estudo de caso que a
pesquisa dirigida aos estgios de explorao, classificao e desenvolvimento de hipteses
do processo de construo do conhecimento. Tambm relatam que, geralmente, uma ou mais
entidades (pessoa, grupo, organizao) so examinadas.
De acordo com Hamel et al. (1993) o estudo de caso emprega vrios mtodos como
entrevistas, observao participante e estudos de campo. Bell (1989) concorda, mas ressalta
que embora os mtodos de coleta de dados mais comuns em um estudo de caso sejam a
observao e as entrevistas, nenhum mtodo pode ser descartado. Os mtodos de coleta de
informaes so escolhidos de acordo com a tarefa a ser cumprida.
O trabalho de Hartley (1994) refora a ligao entre os estudos de caso e mtodos
qualitativos: Dentro da ampla estratgia de pesquisa do estudo de caso, pode-se empregar
vrios mtodos qualitativos, quantitativos ou ambos embora a nfase seja empregar
mtodos qualitativos, em funo dos tipos de problemas que geralmente so associados e
melhor compreendidos por meio de estudos de caso. Os mtodos mais utilizados so:
observao, observao participante e entrevistas (semi-estruturadas ou no estruturadas).
Pode-se utilizar tambm questionrios para complementar os dados obtidos a partir de
observao e entrevistas.
Mais recentemente, Nielsen (2004) defendeu o uso de estudos qualitativos com a
justificativa de que esses so menos frgeis e com menor possibilidade de falhar em pontos
fracos da metodologia empregada. Segundo esse autor, mesmo que o estudo no seja perfeito,
possvel obter bons resultados utilizando-se mtodos qualitativos que se fundamentam em
usurios e na observao de seus comportamentos.
109
Assim, o mtodo de pesquisa adotado neste trabalho foi o estudo de caso, utilizando-
se mtodos qualitativos embasados em observao, entrevistas e questionrios. Esses estudos
foram realizados com a finalidade de observar o comportamento dos desenvolvedores de
aplicaes de diferentes domnios, com diferentes nveis de habilidade na utilizao da
abordagem proposta, possibilitando o refinamento da mesma e uma anlise da contribuio
da proposta no processo de projeto de interfaces multimodais.
6.3 Viso geral dos estudos de caso
Para realizar tanto a proposta como a avaliao da abordagem e do ambiente de
autoria foram conduzidos trs estudos de caso, nos quais foram desenvolvidos 5 projetos de
aplicaes multimodais, apresentados no Quadro 7.
Quadro 7 - Descrio geral dos estudos de caso
EC1 EC2 EC3
Hipteses DR coletado ajuda na
soluo de problemas de
outros grupos de
desenvolvedores.
Wiki sistematiza o
processo de captura e
utilizao de DR.
Problemas de usabilidade
diminuem quando se usa
DR coletado previamente.
Problemas de usabilidade
gravados pela MMWA no
se manifestam em projetos
subsequentes.
Menos problemas de
usabilidade ocorrem quando
se utiliza a MMWA.
MMHE e MMLOG so
complementares.
Anlise dos Log e
aplicao de regras de
associao permitem a
identificao de padres de
interao.
MMWA-ae aumenta a taxa de
reutilizao de cdigo.
Gerao de cdigo e prottipo de
interface so mais rpidos com o
MMWA-ae.
Menos problemas de usabilidade
ocorrem com o uso do MMWA-
ae.
Foco Coleta, armazenamento e
recuperao de DR.
MMWA MMWA-ae
Projetos Sistema de aluguel de
carros.
Sistema de pagamentos de
conta de telefone, sistema de
navegao em mapas.
Sistema de aluguel de carros,
sistema para apresentao de
palestras
Equipe 24 pessoas 4 pessoas 2 pessoas
Tecnologia X+V, Java, JSP, Hibernate,
PostgreeSQL, JSGF
X+V, JSP, ECMAScript,
JSGF, ActionScript, Adobe
Flex SDK, Google Maps
API
X+V, Java, Hibernate, JSP,
PostgreeSQL, JSGF
Primeiramente, foi realizado um estudo de caso (EC1) para coletar DR utilizando a
primeira verso da MMWA. Aps a finalizao deste estudo de caso, modificaes foram
feitas na MMWA e um novo estudo de caso (EC2) foi planejado e executado com o objetivo
de continuar os testes com a MMWA especificamente na atividade de avaliao de
110
usabilidade. Novas sugestes de melhorias foram adotadas, a ferramenta de autoria MMWA-
ae foi desenvolvida e o ltimo estudo de caso (EC3) foi executado. As sugestes do ltimo
estudo de caso foram incorporadas na MMWA-ae e apresentadas nesta tese no Captulo 5.
Na linha do tempo apresentada na Figura 43 possvel verificar as atividades que
foram desenvolvidas nesta pesquisa at a escrita desta tese. A figura est dividida em 3
grandes ciclos: pesquisa bibliogrfica, abordagem e ferramenta. Cada ciclo composto por
atividades que representam um conjunto de resultados alcanados e marcam um perodo de
tempo e em cada perodo de tempo foram publicados artigos que divulgam os resultados de
cada atividade. Essas publicaes so apresentadas no Captulo 8.
Figura 43 - Linha do tempo das atividades realizadas no doutorado
A seguir so detalhados os estudos de caso realizados.
6.4 Estudo de caso 1
O estudo de caso 1 (EC1) foi proposto com o objetivo de validar as atividades que
compem o ciclo da MMWA e, para cada atividade, testar as tcnicas propostas e estabelecer
um workflow para sua utilizao em conjunto com a coleta, armazenamento e a recuperao
de DR (um exemplo de DR pode ser encontrado no Quadro 6 no Captulo 4).
O EC1 possibilitou o projeto de ferramentas para apoiar as atividades da MMWA,
bem como a coleta, a organizao, a estruturao, o armazenamento e a recuperao de DR,
por meio da proposta de um mecanismo de utilizao de DR com o uso de sistemas Wiki.
Alm disso, foi possvel testar o uso dos princpios e guidelines e suas relaes com as
heursticas em projetos reais, nas avaliaes de usabilidade. Permitiu tambm que fosse
4
W
X
Y
H
S
W
W
S
F
V
I
?
I
G
S
R
L
I
G
M
Q
I
R
X
S
H
I
C
S
\
R
E
D
I
F
4
W
X
Y
H
S
W
W
S
F
V
I
M
R
X
I
V
E
i
h
S
Q
Y
P
X
M
Q
S
H
E
P
>
V
S
T
S
W
X
E
H
E
<
<
D
1
8
Q
?
H
F
D
F
A
?
Y
X
K
7
H
I
R
X
M
J
M
G
E
i
h
S
H
I
>
V
M
R
G
k
T
M
S
W
>
V
S
T
S
W
X
E
H
E
2
L
I
G
O
P
M
W
X
3
K
N
I
?
H
F
S
?
Y
X
K
B
?
O
.
P
F
R
F
B
?
B
C
O
B
?
5
5
>
.
4
2
(
%
B
W
S
H
I
3
?
<
I
P
L
S
V
M
E
W
R
E
<
<
D
1
2
V
M
E
i
h
S
H
S
<
<
6
4
I
<
<
;
=
5
4
2
)
%
B
W
S
H
E
<
<
D
1
I
1
Z
E
P
M
i
m
I
W
H
I
B
W
E
F
M
P
M
H
E
H
I
<
I
P
L
S
V
M
E
W
R
E
<
<
D
1
7
N
K
G
C
P
K
C
1
C
O
C
J
R
K
H
R
F
I
C
J
P
K
B
K
5
5
>
.
!
?
C
4
2
*
%
B
W
S
H
S
<
<
D
1
%
E
I
<
I
P
L
S
V
M
E
W
<
<
D
1
%
E
I
4
W
G
V
M
X
E
H
E
A
I
W
I
I?N"#* GQJ"#* ?EK"#* KQP"#* JKR"#* BCS"#* DCR"#+ ?@N"#+ ?EK"#+ JKR"#+ G?J"#, GQJ"#, ?EK"#, G?J"$# ?@N"$# OCP"$#
;MRLE HS AIQTS <<D1%EI
7COMQFO? /F@HFKENWDFA? .@KNB?ECI 3CNN?ICJP?
111
identificada uma forma de se pensar na formalizao de padres de projeto de acordo com o
DR armazenado.
6.4.1 Definio do estudo de caso
Objeto de estudo:
O objeto de estudo foi o monitoramento do projetista de interfaces multimodais Web
utilizando a abordagem proposta para a coleta de requisitos, especificao de tarefas, criao
de prottipos, identificando problemas recorrentes de projeto da interao multimodal,
propondo e discutindo solues e registrando todo o raciocnio envolvido na forma de DR.
Motivaes:
" A tecnologia multimodal emergente e s foram encontrados na literatura,
mtodos e tcnicas que facilitam a gerao de cdigo com pouco ou nenhum
apoio para testes de usabilidade e gravao de conhecimento de projeto para uso
futuro.
" O DR pode ser entendido como uma organizao do conhecimento fundamentado
na experincia do projetista. Padres de projeto so fundamentados em decises
de projeto bem estabelecidas. A falta de experincia no projeto de sistemas e
interao multimodal e o fato de no haver corpo de DR suficiente de aplicaes
multimodais de sucesso de onde padres pudessem ser identificados, justificam o
propsito deste estudo de caso.
" Padres de projeto j esto estabelecidos para o projeto de interfaces grficas Web
e acredita-se que a estrutura formal dos padres fazem deles uma ferramenta
importante para modelar novos tipos de interao, como a multimodal.
6.4.2 Planejamento do estudo de caso
Proposta:
Utilizao da MMWA para o projeto de interfaces multimodais. Registro de DR de
maneira semi automatizada utilizando templates e namespaces na DokuWiki. Monitorar os
problemas sendo resolvidos por projetistas e desenvolvedores experientes em projeto Web,
que receberam treinamento na tecnologia multimodal, e que atuam em um projeto
colaborativo utilizando a MMWA.
112
Foco qualitativo:
Eficcia na coleta, armazenamento e recuperao de DR e eficcia no uso da MMWA
para o projeto de interfaces multimodais.
Perspectiva:
O estudo de caso foi realizado sob o ponto de vista de estudantes que possuem
experincia no desenvolvimento de interfaces Web, no curso de ps-graduao na disciplina
Hipermdia do ICMC-USP, durante o primeiro semestre de 2008.
Hipteses e Resultados Preliminares:
A seguir sero apresentadas as principais hipteses que guiaram a conduo do EC1 e
os resultados preliminares obtidos. Uma anlise mais detalhada dos resultados ser
apresentada no Captulo 7.
Hiptese 1: o DR serve como uma ferramenta de comunicao entre os projetistas.
Resultado: em alguns casos houve a verificao de que a soluo adotada por um
grupo est presente no projeto de um outro grupo e a verificao da comunicao de
participantes de diferentes grupos em um mesmo DR. O DR pode ser usado como ferramenta
para diversas finalidades como ser apresentado na Seo 7.7.
Hiptese 2: a MMWA promove o uso de DR.
Resultado: as questes mais genricas do DR gravado foram includas na checklist
para que o projetista tenha uma ferramenta que auxilie na verificao de seu projeto. Quando
o projetista no utiliza um DR j gravado para resolver um problema nas fases de projeto ou
desenvolvimento, ele acaba sendo utilizado nas avaliaes de usabilidade por meio do uso
das checklists. Dessa forma, o problema corrigido antes da entrega do produto para os testes
com usurios. No Quadro 8 apresenta-se um resumo quantitativo sobre a utilizao de DR no
EC1. Pode-se observar o nmero de questes capturadas, bem como o nmero de argumentos
e posies registradas e o nmero de consultas realizadas pelos projetistas.
Quadro 8 - Uso de design rationale no estudo de caso 1
EC1
Questes de DR capturadas 36
Argumentos e Posies registradas 472
Consultas ao DR registrado 120
113
Hiptese 3: o DR registrado permite a identificao de padres de projeto.
Resultado: para a identificao de padres de projeto necessrio que a mesma
soluo seja usada em diferentes projetos. Foi observado que questes similares com
solues iguais foram utilizadas entre os diferentes grupos (diferentes projetos em um mesmo
contexto). Pretende-se observar se esse comportamento mantido nos prximos estudos de
caso e apresentar os resultados no Captulo 7.
6.4.3 Execuo do estudo de caso
O estudo de caso foi realizado, em ambiente acadmico, por 24 projetistas e
desenvolvedores divididos em 6 grupos, fora da sala de aula e sem superviso, portanto, os
desenvolvedores tiveram a liberdade de determinar seus prprios cronogramas para cumprir
as atividades propostas. Um projeto multimodal envolvendo aluguel de carros utilizando
interfaces de voz e grfica foi desenvolvido por todos os grupos.
A especificao de requisitos foi fornecida aos participantes e foi solicitado que eles
realizassem as atividades de desenvolvimento de software e documentao de DR, aps um
treinamento de aproximadamente 8 horas sobre desenvolvimento de interfaces multimodais
Web utilizando X+V, design rationale e sobre os modelos e as ferramentas utilizadas.
Todos os grupos tinham acesso ao DR coletado por todos os projetistas e as
discusses podiam ocorrer entre os grupos. Isso permitiu identificar que houve cooperao
entre os projetistas de diferentes grupos e apesar do sistema ser o mesmo, diferentes
problemas surgiam e medida que os problemas eram corrigidos em um projeto, a soluo
era disponibilizada para os outros grupos. A realizao de avaliaes heursticas no final do
EC permitiu que a checklist desenvolvida e o DR coletado pelos grupos facilitassem a
identificao de problemas de usabilidade nas interfaces projetadas. Dessa forma, se um
grupo no tivesse consultado algum DR coletado por outro grupo, o erro poderia ser
identificado na fase de avaliao de usabilidade e corrigido no prximo ciclo da abordagem.
Os artefatos gerados pelos grupos foram utilizados para estabelecer um conjunto de
requisitos para o projeto da ferramenta de autoria, que seria criada mais adiante nesta
pesquisa. Os artefatos gerados por um dos grupos de desenvolvimento pode ser encontrado
no Apndice E.
114
A tarefa de desenvolvimento foi considerada cumprida quando os alunos
demonstraram o software sendo executado em um ambiente Web e discutiram sobre o DR
coletado e as avaliaes de usabilidade realizadas.
6.5 Estudo de Caso 2
O segundo estudo de caso (EC2) foi realizado no ambiente acadmico e teve como
contribuio a publicao de uma monografia de concluso de curso de graduao em
Bacharelado em Cincia da Computao do ICMC-USP, e a orientao de um aluno de
graduao voluntrio.
O EC2 foi proposto com o objetivo de validar as atividades que compem o ciclo da
MMWA aps as modificaes decorrentes dos problemas encontrados no EC1, ou seja,
fundamentado na experincia do estudo de caso anterior, a abordagem foi modificada para
melhor atender aos requisitos dos projetistas e desenvolvedores de aplicaes multimodais
Web.
O EC2 tambm possibilitou a verificao dos mecanismos de avaliao de usabilidade
propostos na quinta atividade da MMWA, bem como a especificao de componentes de
software multimodal para reutilizao de software. Componentes multimodais foram criados,
por exemplo: dilogos, gramticas, cdigo para sincronismo e fuso de interfaces, entre
outros.
Foi possvel tambm testar o uso do DR coletado anteriormente alm de permitir
novas coletas para aumentar a base de dados de DR. No final do EC2 a ferramenta de autoria
MMWA-ae foi desenvolvida para servir como um framework para as atividades da MMWA.
Objeto de estudo:
O objeto de estudo composto pelo conjunto de projetistas e testadores de interfaces
multimodais Web utilizando a abordagem proposta para a coleta de requisitos, especificao
de tarefas, criao de prottipos, utilizao de DR armazenado, criao de novos DR e
aplicao de mecanismos automticos de avaliao de usabilidade em interfaces multimodais.
Motivaes:
" Responder perguntas como: Qual comportamento dos usurios que navegam na
Web com interfaces multimodais? Como eles interagem com as aplicaes? Quais
115
suas necessidades? Quais so suas dificuldades? Como elas identificam elementos
funcionais de uma aplicao?
" Utilizar tecnologias para enriquecer a forma de interao para as diferentes
necessidades e preferncias em interfaces multimodais.
" Testar os dois mecanismos para avaliao de usabilidade propostos na MMWA,
analisar os logs gerados automaticamente e identificar pontos falhos na interface
que podem ser melhorados em ciclos de desenvolvimento subseqentes.
Proposta:
Duas aplicaes Web foram desenvolvidas. A primeira, uma aplicao utilizando a
API do Google Maps com o objetivo de utilizar tecnologias para enriquecer a forma de
interao, define rotas entre dois locais especificados pelo usurio e possibilita seguir o passo
a passo atravs de vias pblicas para se chegar de um local ao outro. A segunda, uma
aplicao para o pagamento de contas em uma empresa de telefonia fictcia. Criou-se tambm
um mecanismo automtico de avaliao de usabilidade como forma de identificar padres de
interao dos usurios.
Foco qualitativo:
Eficincia na reutilizao de cdigo fonte previamente criado e eficcia na avaliao
de usabilidade com base no DR armazenado.
Perspectiva:
O estudo de caso foi realizado sob o ponto de vista de estudantes que possuem
experincia no desenvolvimento de interfaces Web, em projetos de concluso de curso de
graduao do ICMC-USP, durante o primeiro semestre de 2009.
A seguir so apresentadas as principais hipteses que guiaram a conduo do EC2 e
os resultados preliminares obtidos. Uma anlise mais detalhada dos resultados ser
apresentada no Captulo 7.
Hiptese 1: os problemas de usabilidade gravados no DR da MMWA no se repetem
e o nmero de problemas de usabilidade encontrado menor do que no EC anterior.
116
Resultado: as estratgias de preveno e correo de erros e de confirmao de
entradas do usurio que apresentam caractersticas identificadas no DR foram utilizadas no
estudo de caso. Foi possvel identificar que os problemas presentes no EC1 no ocorreram no
EC2 e no EC3.
Hiptese 2: mtodos empricos e analticos de avaliao de usabilidade so
complementares.
Resultado: apenas parte dos problemas que realmente ocorrem nos testes com
usurios identificado durante a avaliao heurstica e os problemas repetidos decrescem
medida que os estudos de caso so realizados como pode ser observado no Quadro 9.
Quadro 9 - Dados gerais das avaliaes de usabilidade nos Estudos de Caso executados com
a MMWA
EC1 EC2 EC3
Projeto1 Projeto2 Projeto3 Projeto4 Projeto5
Problemas encontrados com o
MMHE
12 8 7 3 0
Problemas encontrados com o
MMLOG
9 9 7 3 3
Total de problemas (no
repetidos)
17 14 13 6 3
Hiptese 3: anlise de log permite identificar padres de interao.
Resultado: a anlise de logs permite identificar as propriedades CARE utilizadas na
interao em conjunto com o uso de regras de associao permite identificar comportamentos
dos usurios.
O estudo de caso foi realizado por quatro pessoas que desenvolveram duas aplicaes
multimodais: um sistema multimodal para pagamento de contas de telefone e um sistema de
localizao de rotas em um mapa.
A equipe de projeto foi responsvel pela utilizao da MMWA para todas as
atividades de projeto, desde a especificao de requisitos at o desenvolvimento de software,
documentao de DR e testes de usabilidade.
A equipe trabalhou em todas as atividades do ciclo da MMWA, desde a obteno de
requisitos, o estudo de tecnologias e o desenvolvimento de aplicaes ricas para Web, a
117
criao do protocolo de avaliao de usabilidade e a avaliao dos logs gerados nas
interaes remotas.
O sistema de localizao de rotas em um mapa, desenvolvido nesse estudo de caso,
um exemplo interessante de aplicao da MMWA, pois mostra a aplicao da abordagem em
um projeto com tecnologias diferentes das empregadas nos outros estudos de caso.
Para essa aplicao, algumas restries, documentadas nas atividades de projeto da
MMWA foram inicialmente identificadas e documentadas na forma de DR. Uma lista com o
resumo do DR coletado foi construda para auxiliar na preveno de erros e na modelagem da
aplicao, identificar as limitaes da aplicao e para realizar a avaliao de usabilidade. A
seguir so apresentados os trechos de DR coletados no EC2 que foram organizados na forma
de problemas e solues para facilitar a formalizao de padres de projeto:
" Gramtica usada no reconhecimento de voz:
o Problema: a entrada de voz reconhecida atravs de uma gramtica pr-
definida que aceita ou no o comando de voz. Esse reconhecimento por
meio de uma gramtica impe algumas restries quanto quantidade de
palavras reconhecidas. Isso pode vir a ser um problema para aplicaes
que possuem um nmero grande de possveis entradas, como o caso
dessa aplicao.
o Soluo: a soluo especificar um domnio restrito de palavras para
interao por voz fundamentado nos dados obtidos no Modelo
Comportamental e no modelo de tarefas. Assim, haver diminuio da
quantidade de palavras aceitas pela gramtica, mas ser possvel realizar
os testes de usabilidade. Ainda possvel subdividir os tokens em grupos,
seguindo alguma lgica e atravs desses grupos, aplicar filtros que
especificam cada vez mais para um subconjunto menor de escolhas.
" Transies entre as tarefas:
o Problema: as transies por interaes de voz podem ser controladas por
meio de mtodos de sincronizao, mas as transies podem ser feitas
utilizando o teclado ou mouse. Nada impede do usurio acessar tarefas
finais sem ter passado por tarefas intermedirias.
o Soluo: para esse problema, mensagens podem ser exibidas para alertar o
usurio sobre a necessidade de realizar tarefas anteriores que no foram
realizadas.
118
" Escolha dos locais de partida e chegada:
o Problema: as escolhas dos locais de partida e chegada pode ser feita de
duas formas: por opes pr-estabelecidas ou digitadas (livres). Na
primeira tem-se um ambiente mais controlado, mas as opes para o
usurio so limitadas. Na segunda tem-se maior liberdade de escolha, mas
o geolocalizador do Google Maps
11
pode no prever tal entrada.
o Soluo: a soluo dar a liberdade de escolha para o usurio e caso o
geolocalizador no preveja a entrada uma mensagem de alerta emitida e
um exemplo fornecido, como estratgia de recuperao de erro.
" API JavaScript Google Maps:
o Problema: a API JavaScript Google Maps possui mtodos que no so
mais previstos no XHTML, como o document.write(). Isso impossibilita o
desenvolvimento utilizando esta API.
o Soluo: a implementao do mapa dever ser feita utilizando a API
ActionScript Google Maps.
" API ActionScript Google Maps:
o Problema: o mapa sendo desenvolvido em arquitetura Flex impossibilita a
adio de um manipulador VXML no mapa. Ou seja, caso o usurio desvie
o foco para o mapa nenhuma interface de voz estar disponvel.
o Soluo: este problema resolvido capturando o evento de foco dentro da
aplicao Flex e retornando o foco para algum elemento XHTML que
tenha um manipulador da interface de voz.
As tarefas identificadas na segunda atividade da MMWA (IT) foram fundamentadas a
partir dos cenrios criados da primeira atividade (MCI). Para representar as tarefas e as
possveis transies entre elas foi utilizado o Diagrama de Transio de Estados, que indica a
tarefa inicial, tarefas intermedirias e a tarefa final e os eventos que ocorrem entre essas
tarefas.
Os elementos grficos que representam as tarefas (RT) foram dispostos em uma
seqncia lgica, seguindo as transies previstas. A Figura 44 ilustra o posicionamento
adotado.
11
http://maps.google.com.br/
119
Figura 44 - Disposio dos elementos grficos no sistema de localizao de rotas.
Em uma aplicao multimodal importante que as interfaces estejam sincronizadas.
A modelagem da comunicao e o sincronismo das interfaces constituem a quarta atividade
(AS) na qual tambm se desenvolve o prottipo. O diagrama da Figura 45 representa a
comunicao entre as camadas da aplicao para realizao do sincronismo entre as
modalidades.
O sincronismo em aplicaes X+V pode ser feito de duas formas. Umas delas a
utilizao do elemento <sync> que a prpria linguagem oferece. Esta forma mais simples e
organizada de se implementar o sincronismo. Outra forma a utilizao de mtodos
JavaScript que podem ser chamados por elementos X+V. Essa opo apresenta um grau de
liberdade maior, permitindo que qualquer elemento XHTML seja modificado atravs do
DOM, alm da possibilidade de se chamar outros mtodos no sincronismo. Nesta aplicao
utilizou-se esta ltima opo pelo fato do mapa ter que ser sincronizado de acordo com a
tarefa.
Figura 45 - Diagrama das camadas da aplicao de localizao de rotas do EC2.
120
A sincronizao ocorre da seguinte forma: quando uma interao por voz efetuada,
chama-se um mtodo JavaScript (1) que sincroniza a entrada de voz com o elemento grfico
XHTML (2) associado ao formulrio de voz. Ou seja, a interpretao do comando de voz
aceita pela gramtica do formulrio VoiceXML passada para o elemento grfico que
representa a tarefa. O mtodo JavaScript responsvel por sincronizar as interfaces de uma
tarefa tambm sincroniza o mapa chamando um mtodo ActionScript (3). Este por sua vez, se
comunica com o servidor Google Maps (5), atravs dos mtodos fornecidos na API
ActionScript do Google Maps e recebe as informaes necessrias (6) para renderizar o mapa
de acordo com a tarefa que est sendo realizada. Essas informaes recebidas (6) podem ser
repassadas, (4) e (2), para que a informao seja sincronizada com as interfaces de voz e
grfica. Por exemplo, na realizao da tarefa de obter os passos necessrios para se chegar do
local de partida at o de chegada, a informao do passo retornada pelo servidor Google
Maps (6), essa informao repassada para as interfaces X+V (4 e 2), para que a informao
seja ouvida e observada graficamente. Assim, quando o usurio interage com a aplicao na
realizao de uma tarefa, tanto as interfaces criadas na linguagem X+V quanto o mapa,
acessado pela interface da API ActionScript do Google Maps, so sincronizados.
Na Figura 46 esto os elementos existentes nas interfaces multimodais para cada uma
das tarefas da aplicao e a associao de cada elemento visual XHTML com o respectivo
formulrio de voz VXML que se mantem sincronizado. A ativao do formulrio de voz est
associada ao foco do elemento XHTML que representa a tarefa. Por exemplo, quando o
elemento place1Input focado, o formulrio VoiceXML que representa a tarefa
(choose_place_1) ativado. O mesmo ocorre para place2Input com choose_place_2,
confirmButton com confirm_chooses e stepText com step_commands. Os elementos
backStepButton e nextStepButton no possuem formulrios de VoiceXML associados a
eles diretamente mas esto indiretamente sincronizados com step_commands atravs de
stepText.
A descrio dos elementos XHTML mencionados anteriormente apresentada a
seguir:
" place1Input: representa a interface grfica da tarefa (T1) de escolher o local de
partida;
" place2Input: representa a interface grfica da tarefa (T2) de escolher o local de
chegada;
121
" confirmButton: representa a interface grfica da tarefa (T3) de confirmar os locais
escolhidos;
" stepText: representa a interface grfica (T4) onde a informao do passo ser
descrito;
" backStepButton: representa a interface grfica (T4) onde o usurio optar por
voltar para o passo anterior;
" nextStepButton: representa a interface grfica (T4) onde o usurio optar por
seguir para o prximo passo.
A descrio dos elementos VoiceXML mencionados anteriormente apresentada a
seguir:
" choose_place_1: representa o formulrio de voz para a tarefa (T1) de escolher o
local de partida;
" choose_place_2: representa o formulrio de voz para a tarefa (T2) de escolher o
local de chegada;
" confirm_chooses: representa o formulrio de voz para a tarefa (T3) de confirmar
os locais de partida e chegada;
" step_commands: representa o formulrio de voz para as tarefas (T4) de seguir para
o prximo passo ou voltar para o passo anterior;
Figura 46 - Elementos X+V da aplicao de localizao de rotas do EC2.
Na Figura 47 so apresentados os mtodos usados para sincronizar os elementos das
interfaces da Figura 46 e o mapa. O mapa sincronizado por meio de mtodos JavaScript,
apresentados na sequncia, que chamam mtodos ActionScript da aplicao Flex responsvel
por renderizar o mapa.
122
" setPlace1(): sincroniza place1Input, choose_place_1 e o mapa atravs do mtodo
goTo(str,zoom);
" setPlace2(): sincroniza place2Input, choose_place_2 e o mapa atravs do mtodo
goTo(str,zoom);
" confirmDirection(): sincroniza confirmButton, confirm_chooses e o mapa atravs
do mtodo goFromTo(from,to);
" writeNextStep(): sincroniza stepText, nextStepButton, step_commands e o mapa
atravs do mtodo nextStep();
" writeBackStep(): sincroniza stepText, nextStepButton, step_commands.e o mapa
atravs do mtodo backStep();
" goTo(str,zoom): chama o mtodo da aplicao Flex que renderiza o mapa
exibindo o local e o zoom especificado;
" goFromTo(from,to): chama o mtodo da aplicao Flex que renderiza o mapa
exibindo a rota do local de partida para o local de chegada;
" nextStep(): chama o mtodo da aplicao Flex que obtm o prximo passo;
" backStep(): chama o mtodo da aplicao Flex que obtm o passo anterior.
Figura 47 - Mtodos JavaScript da aplicao de localizao de rotas do EC2.
Na Figura 48 esto representados os mtodos ActionScript da aplicao Flex
utilizados para renderizao do mapa. Esses mtodos, descritos a seguir, so retirados da
aplicao X+V de forma que possam ser chamados com cdigo JavaScript.
" goTo(p1,zoom): renderiza o mapa exibindo o local e o zoom especificado;
123
" goFromTo(from,to): renderiza o mapa exibindo a rota do local de partida para o
local de chegada;
" nextStep(): obtm o prximo passo;
" backStep(): obtm o passo anterior.
Figura 48 - Mtodos ActionScript da aplicao de localizao de rotas do EC2.
No Quadro 10 apresentada, para cada tarefa, a associao das interfaces grfica e de
voz com os respectivos mtodos sincronizadores.
Quadro 10 - Sincronizao das interfaces do sistema de localizao de rotas do EC2.
Tarefa Elemento
Grfico
Formulr
io de Voz
Ativao Mtodo
ActionScript
Renderizador
do Mapa
Metodos
JavaScript de
Interface com
a Aplicao
Flex
Mtodo
JavaScript
Sincronizador
Selecionar
lugar de
partida
place1Input choose_pl
ace_1
Foco no
elemento
grfico
goTo(p1,zoom) goTo(p1,zoom) setPlace1()
Selecionar
lugar de
chegada
place2Input chosse_pla
ce_2
Foco no
elemento
grfico
goTo(p2,zoom) goTo(p2,zoom) setPlace2()
Confirmar
lugar de
partida e
chagada
confirmBut
ton
confirm_c
hooses
Foco no
elemento
grfico
goFromTo(p1,p
2)
goFromTo(p1,p
2)
confirmDirectio
n()
Obter
Passos
stepText step_com
mands
Foco no
elemento
grfico
nextStep() nextStep() writeNextStep()
backStep() backStep() writeBackStep()
Cabe ressaltar que os artefatos gerados pelos desenvolvedores foram utilizados para
estabelecer um conjunto de requisitos para o projeto do mecanismo de avaliao de
usabilidade utilizado na ferramenta de autoria MMWA-ae.
A tarefa foi considerada cumprida quando foram apresentados os resultados obtidos
em uma monografia de concluso de curso de graduao (MURAKAMI, 2009).
124
6.6 Estudo de Caso 3
O Estudo de Caso 3 foi proposto com o objetivo de validar o uso da ferramenta de
autoria desenvolvida para facilitar a utilizao da MMWA em projetos de interfaces
multimodais Web, por meio da criao de prottipos rpidos e avaliaes de usabilidade
remotas.
Objeto de estudo:
Projetistas, desenvolvedores e testadores de interfaces multimodais Web utilizando o
ambiente de autoria desenvolvido para suas atividades no projeto de interfaces multimodais
Web.
Motivaes:
" Necessidade de um ambiente de autoria para apoiar a utilizao da MMWA de
forma automatizada e simplificada.
" Necessidade de uma ferramenta para realizar a coleta, o armazenamento e a
recuperao de DR de forma no intrusiva e semi automatizada.
Proposta:
Avaliar o uso da ferramenta de autoria para verificar se ela implementa as atividades
da MMWA e se ela auxilia a equipe de projeto em suas atividades de projeto,
desenvolvimento e testes de interfaces multimodais Web.
Foco qualitativo:
Criao rpida de prottipo de interface multimodal com usabilidade, reutilizao de
interfaces multimodais e fcil utilizao do DR.
Perspectiva:
O estudo de caso foi realizado sob o ponto de vista de profissionais que possuem
experincia no desenvolvimento de interfaces Web e de voz, em um projeto acadmico no
ICMC-USP, durante o primeiro semestre de 2010.
125
A seguir sero apresentadas algumas hipteses que guiaram a conduo do EC3 e os
resultados preliminares obtidos. Uma anlise mais detalhada dos Resultados ser apresentada
no Captulo 7.
Hiptese 1: gerao rpida de cdigo fonte
Resultados: comparando-se o tempo para obteno do cdigo fonte que serviu para a
execuo de testes com usurios, o MMWA-ae gerou o prottipo aproximadamente 8 vezes
mais rpido do que na aplicao de referncia. Isto ocorre pois alm dos componentes
multimodais disponveis existem padres de projeto implementados e que facilitam a gerao
do cdigo.
Hiptese 2: projetista comete menos erros de usabilidade
Resultados: quando os componentes de software, os padres de projeto e tambm o
DR so utilizados pelo projetista/desenvolvedor, menos erros de usabilidade so cometidos,
pois os artefatos desenvolvidos trazem o raciocnio que j foi implementado e testado em
outro projeto.
Hiptese 3: MMWA-ae promove a reutilizao de cdigo fonte
Resultados: foi conseguido um bom percentual de reutilizao nas aplicaes
desenvolvidas com o MMWA-ae. Para o sistema multimodal para aluguel de carros, obteve-
se 83% de reutilizao com apenas 3.2% de mtodos no desejados.
O estudo de caso foi realizado com 2 projetistas especialistas em interfaces
multimodais que receberam treinamento sobre a MMWA e o ambiente de autoria e
desenvolveram duas aplicaes envolvendo interfaces multimodais: um sistema multimodal
para aluguel de carros e um sistema de apresentaes de palestras.
O sistema multimodal para aluguel de carros foi escolhido por ter sido o mesmo
projeto desenvolvido no primeiro estudo de caso. A interface do projeto selecionado do EC1
est representada na Figura 49.
A escolha de uma aplicao de referncia possibilitou obter medidas de comparao
entre as aplicaes geradas com e sem o MMWA-ae, como, o tempo de desenvolvimento das
interfaces, o nmero de linhas de cdigo geradas pelo MMWA-ae, o nmero de problemas de
usabilidade, alm de informaes sobre o uso de DR em aplicaes do mesmo tipo.
126
Na Figura 50 possvel observar a interface desenvolvida no EC3 com o auxlio do
MMWA-ae sendo executada em um simulador de dispositivos mveis.
Na Figura 51 pode-se observar a interface multimodal do sistema de apresentaes de
palestras desenvolvida no EC3 que foi utilizada para apresentao de um artigo resultante
desta tese no 28th ACM International Conference on Design of Communication (NETO;
FORTES, 2010).
A equipe de projeto utilizou a MMWA-ae no EC3 para todas as atividades de projeto,
desde a especificao de requisitos at o desenvolvimento de software, documentao de DR
e testes de usabilidade.
A tarefa foi considerada cumprida quando as interfaces foram disponibilizadas para os
testes remotos.
Figura 49 - Interface desenvolvida no EC1, sem o auxlio do MMWA-ae
Figura Figura 50 - Interface do EC3, projetada com o MMWA
Figura 51
Interface do EC3, projetada com o MMWA
plataforma de testes de aplicaes mveis.
51 51 - Sistema de apresentaes de palestras desenvolvido no EC3
Sistema de apresentaes de palestras desenvolvido no EC3
127
Interface do EC3, projetada com o MMWA-ae, sendo executada em uma
Captulo 6
ae, sendo executada em uma
Estudos de caso
128
6.7 Consideraes finais sobre os estudos de caso
Neste captulo apresentaram-se os trs estudos de caso realizados nesta tese.
As medidas qualitativas utilizadas para avaliar o desempenho da abordagem e do
ambiente de autoria foram:
1) A verificao que os problemas de usabilidade no se repetem em estudos de
caso subsequentes.
2) O feedback obtido com questionrios aplicados aos desenvolvedores (exemplo
de questionrio no Apndice D).
3) O feedback obtido com os questionrios aplicados nos testes com usurios.
4) A verificao da utilizao do DR nos estudos de caso com as caractersticas
do DR presentes nas interfaces desenvolvidas.
5) A possibilidade da escrita de padres de projeto com base no DR coletado nos
estudos de caso.
6) A facilidade para a criao de componentes de software fundamentados nas
informaes presentes no DR coletado.
7) A identificao de padres de interao utilizando o MMLOG em conjunto
com as propriedades CARE e regras de associao.
As medidas quantitativas utilizadas para avaliar o desempenho da abordagem e do
ambiente de autoria foram:
8) A verificao que os problemas e as severidades diminuram de um estudo de
caso para outro nas avaliaes de usabilidade com as interfaces projetadas.
9) A verificao dos dados presentes nos grficos e tabelas gerados com o
MMLOG.
10) O tempo de desenvolvimento de interfaces,
11) A taxa de reutilizao de cdigo.
Instrumentao: o material fornecido aos participantes para a execuo dos estudos
de caso est publicado na forma de relatrio tcnico, referenciado na Seo 8.4 , e
composto por material didtico sobre X+V, princpios, guidelines e checklists para o
desenvolvimento de interfaces multimodais Web, diretivas para executar o estudo de caso,
requisitos do sistema e treinamento sobre DR.
Ameaas validade: importante observar que os estudantes receberam notas de
avaliao nas disciplinas por suas participaes nos estudos. H o risco de que o incentivo
influencie os resultados. Alm disso, os estudos de caso foram realizados com alunos de
graduao e ps-graduao. Considera-se aceitvel a realizao dos estudos com alunos sobre
129
um tpico de estudo nas disciplinas de graduao e ps-graduao em Hipermdia, pois sabe-
se que em geral os alunos participam de equipes que desenvolvem os projetos de tal natureza
(projetos de interfaces Web) seja no ambiente acadmico ou no ambiente profissional.
No prximo captulo so analisados os resultados obtidos com a realizao dos
estudos de caso.
Captulo 7 - Anlise dos Resultados dos Estudos de Caso
131
Captulo 7. Anlise dos Resultados dos
Estudos de Caso
Como foi exposto no captulo anterior, trs estudos de caso foram realizados
utilizando a MMWA e permitiram apresentar resultados sobre a abordagem e seu ambiente
de autoria.
Neste captulo so discutidos os principais resultados que evidenciam as hipteses
definidas nos estudos de casos, visando proporcionar uma anlise mais detalhada das
questes envolvidas.
Na Seo 7.2 so discutidos os tpicos que mostram a diminuio dos problemas de
usabilidades medida que os estudos de caso foram sendo executados. Nas Sees 7.3, 7.4 e
7.5 so discutidos os resultados obtidos com as principais estratgias de dilogo utilizadas no
projeto das interfaces multimodais. Nas Sees 7.6 e 7.7 so apresentados como Regras de
Associao e propriedades CARE podem ser utilizadas para identificar padres e problemas
de interao em testes com usurios.
Nas Sees 7.8 e 7.9 so discutidos os aspectos relacionados ao DR, como a
documentao de software e a tcnica usada para identificar padres de projeto.
Nas duas ltimas Sees, 7.10 e 7.11 so feitas consideraes sobre reutilizao de
cdigo e tempo gasto para obteno de prottipos de interfaces multimodais.
7.2 Usabilidade das interfaces geradas pelo MMWA-ae
Com a utilizao do MMHE e do MMLOG para a realizao de avaliaes de
usabilidade foi possvel identificar que os problemas de usabilidade encontrados no primeiro
estudo de caso no estavam presentes nas interfaces criadas nos outros dois estudos de casos,
principalmente no terceiro estudo de caso, que foi o mesmo projeto de locadora de carros
desenvolvido no primeiro estudo de caso, mas executado por uma equipe diferente e usando o
MMWA-ae.
Argumenta-se que isso foi possvel devido ao conhecimento de DR disponvel no
MMWA-ae e ao mecanismo de sugesto de solues para problemas de usabilidade
fundamentado em DR, checklists, princpios e padres de projeto, que permite ao projetista
132
escolher uma soluo para implementar suas idias, resolver problemas e entender o
raciocnio utilizado na soluo.
Alm disso, os princpios e as checklists de usabilidade para interfaces multimodais
so automaticamente implementados no cdigo fonte gerado e tambm contriburam para o
aumento da usabilidade geral.
Comparando-se os dados dos trs estudos de caso, percebeu-se que os problemas de
usabilidade encontrados diminuram de um estudo de caso para outro, como mostrado no
Quadro 11. Acredita-se que isso aconteceu devido utilizao de DR em projetos
subsequentes e, devido utilizao da avaliao heurstica e dos testes com usurios,
validando as suposies feitas em (DESURVIRE, 1994) a respeito da natureza complementar
dos mtodos de avaliao de usabilidade empricos e analticos. Em outras palavras, apenas
parte dos problemas que realmente ocorrem nos testes com usurios identificado durante a
avaliao heurstica e os problemas encontrados em um mtodo analtico de avaliao de
usabilidade so complementares aos problemas encontrados nos mtodos empricos.
Quadro 11 - Dados gerais dos Estudos de Caso executados com a MMWA
EC1 EC2 EC3
Projeto1 Projeto2 Projeto3 Projeto4 Projeto5
Questes de DR 36 11 10 3 0
Discusses de DR 472 97 75 20 0
Consultas ao DR 120 13 18 45 11
Problemas encontrados
com o MMHE
12 8 7 3 0
Problemas encontrados
com o MMLOG
9 9 7 3 1
Total de problemas (No
repetidos)
17 14 13 6 1
Alm disso, a utilizao do mecanismo de avaliao heurstica da MMWA (o
MMHE) permitiu a obteno de vrios resultados relacionados com a identificao e soluo
de problemas com base nas teorias pesquisadas neste trabalho: DR, princpios de usabilidade
multimodal, listas de verificao (checklists), padres de projeto e as heursticas de
usabilidade de Nielsen (1990). Essa atividade foi importante para que fossem obtidos os
relacionamentos entre os princpios, as checklists e as heursticas, pois o MMWA-ae utiliza
esses relacionamentos em seu modelo de tarefas para sugerir solues apropriadas para
resolver problemas de usabilidade. Exemplos de dados obtidos com o MMHE que permitem
visualizar os relacionamentos mencionados anteriormente so apresentados a seguir (uma
descrio mais detalhada pode ser encontrada no Apndice B):
133
Problema 1: o usurio no sabe o contedo interno de uma caixa de seleo e no
tem alternativa a no ser utilizar a interface de forma grfica, ou seja, o modo voz est
disponvel, mas o usurio no sabe o que pode dizer. Alm disso, mostrar a caixa de seleo
aberta pode ocupar muito espao na interface grfica.
Soluo: Utilizar filtros grficos e de voz para permitir que a interface multimodal
apresente o menor nmero de opes de acordo com o filtro selecionado.
Heursticas:
" Visibilidade do estado sistema: O sistema deve sempre manter os usurios
informados sobre o que est acontecendo, atravs de feedback apropriado dentro
de prazo razovel;
" Reconhecimento ao invs de memorizao: Tornar objetos, aes e opes
visveis. O usurio no deve ter que lembrar informaes de uma parte do dilogo
para outra. Instrues para a utilizao do sistema devem ser visveis ou
facilmente recuperveis sempre que apropriado.
Princpios: Transio Perceptvel; Previsibilidade.
Checklistscom problemas:
" O usurio consegue perceber qual modalidade ele deve utilizar para cada
componente de interface e para cada interface?
" Existe alguma representao visual para auxiliar o usurio na identificao do tipo
de interface disponvel?
" As listas de opes das caixas de seleo esto claras para o usurio?
Exemplo: Encontrar um ponto de referncia em um mapa, filtrando-se por cidade.
Figura 52 - Filtro de voz utilizado na interface grfica
134
Problema 2: para campos que so opcionais, o usurio no sabe o que dizer caso ele
queira deixar o campo em branco. Ajuda apropriada no fornecida quando o erro ocorre.
Soluo: Instruir o usurio para que ele possa executar a prxima tarefa deixando o
campo em branco. possvel usar os contadores de erro e o mecanismo para distinguir tipos
de erro da tecnologia de voz para fornecer a mensagem de erro adequada ao usurio e facilitar
a recuperao de um erro ou o entendimento da tarefa.
Heursticas:
" Preveno de erro: um projeto cuidadoso que previne a ocorrncia de um
problema em primeiro lugar melhor do que boas mensagens de erro;
" Flexibilidade e eficincia de uso: permitir aos usurios personalizar aes
freqentes.
Princpios: Adaptao; Diversidade de usurios e dispositivos de interao;
Tratamento e preveno de erros.
Checklist com problemas:
" O sistema multimodal faz com que usurios cometam erros que no cometeriam
em sistemas apenas com interface grfica?
" Em virtude de mudana ou correo de sua solicitao, o usurio pode alterar suas
entradas usando qualquer modalidade?
Problema 3: as mensagens de ajuda da interface de voz no apresentam termos que
so reconhecidos pela gramtica.
Soluo: Fornecer assistncia focando na tarefa do usurio (por exemplo, uma janela
de ajuda que abre em um elemento <div> quando um evento mouseover acontece ou quando
o usurio solicita ajuda pela interface de voz).
Heursticas:
" Ajuda aos usurios para reconhecer, diagnosticar e se recuperar de erros:
mensagens de erro devem ser expressas em linguagem simples (sem cdigos),
indicar com preciso o problema e sugerir uma soluo construtiva.
" Ajuda e documentao: mesmo que o sistema possa ser usado sem documentao
necessrio fornecer ajuda e documentao, tais informaes devem ser fceis de
pesquisar e centradas na tarefa do usurio. Devem conter uma lista de medidas
concretas a serem realizadas e que no seja demasiadamente grande.
Princpios: Consistncia na interao; Previsibilidade.
Checklist com problemas:
135
" Uma ajuda apropriada fornecida quando ocorre um erro? As mensagens de erro
so expressas em linguagem plena (sem cdigos)? Elas sugerem uma soluo?
" Uma ajuda apropriada fornecida pelo comando help? Essa informao fcil
de ser solicitada e focada na tarefa do usurio?
Problema 4: Usurios com dificuldades em selecionar hora/data.
Soluo: Mostrar claramente que a interface permite entrada multimodal e que os
campos esto bem determinados, mostrando uma data padro, por exemplo. O mecanismo de
ajuda pode mostrar que o sistema aceita entradas de voz como hoje e amanh. Um
algoritmo deve ser utilizado para calcular datas relativas nesse caso.
Heursticas: Correspondncia entre o sistema e o mundo real; Flexibilidade e
eficincia de uso; Ajuda e documentao.
Princpios: Sincronizao, Previsibilidade, Diversidade de usurios e dispositivos de
interao.
Exemplo: Entrada de datas e hora da Figura 53.
Figura 53 - Entrada de datas e hora
Finalmente, a aplicao do MMLOG nos estudos de caso com a MMWA ajudou na
identificao de problemas de interao e de solues que no poderiam ser obtidas ou
propostas realizando apenas a avaliao heurstica (MMHE), como ser apresentado nos
tpicos a seguir. Alm disso, ajudou na identificao de sugestes de melhorias do projeto da
interao na fuso das interfaces grficas com as interfaces de voz permitindo a anlise do
padro de comportamento dos usurios em suas interaes, alm da verificao das
estratgias de preveno/recuperao de erros utilizadas neste trabalho, como ser mostrado
adiante neste captulo.
7.3 Estratgia de recuperao de erros
Basicamente existem dois tipos de erros nas tecnologias de reconhecimento: erro de
no entendimento e erro de interpretao (BOHUS; RUDNICKY, 2008) (OVIATT;
VANGENT, 1996).
136
O erro de no entendimento ocorre quando o sistema falha para obter uma
interpretao da entrada fornecida pelo usurio, por exemplo, quando este diz algo que no
est previsto em uma gramtica de reconhecimento de voz. Neste caso, o sistema precisa
obter novamente uma entrada do usurio com o objetivo de tentar obter um dado para
completar a tarefa.
J o erro de interpretao ocorre quando o sistema obtm uma interpretao
incorreta da entrada do usurio, por exemplo, quando este diz seis e o sistema interpreta
como trs, devido similaridade na pronncia das palavras. Neste caso, o sistema completa
a tarefa com um dado incorreto que pode ou no ser percebido pelo usurio.
A estratgia de preveno e correo de erros est diretamente relacionada ao projeto
da interface, ou seja, o projetista deve escolher a melhor forma para obter a entrada do
usurio, por exemplo, definindo prompts que sejam consistentes com o que apresentado na
interface grfica ou criando mecanismos de confirmao das entradas fundamentando-se em
nveis de confiana de reconhecimento. Apesar disso, algumas estratgias para identificao,
confirmao, correo e recuperao de erros foram utilizadas neste trabalho de acordo com
uma situao especfica (SUHM, 1997; BOHUS; RUDNICKY, 2008) (SUHM, 1997).
" DetailedReprompt: O sistema repete o prompt, incluindo mais detalhes e a opo
de se utilizar outra modalidade.
" MoveOn: O sistema avana para a prxima tarefa, completando com um valor
padro quando possvel.
" YouCanSay: O sistema oferece ao usurio exemplo de falas que ele pode dizer
para completar uma tarefa.
" FullHelp: o sistema fornece uma longa mensagem de ajuda explicando o contexto
da tarefa, as falas que o usurio pode dizer e a opo de se utilizar outra
modalidade.
Essas estratgias foram criadas a partir da identificao de erros nos logs analisados
nos ECs e tambm a partir da coleta de DR. Uma inspeo minuciosa nos logs, tabelas e
grficos gerados pelo MMLOG possibilitou a verificao de que tanto a estratgia utilizada
para a correo de erros de reconhecimento identificada na avaliao heurstica como a do
projeto das gramticas tendo como base o modelo do domnio e o projeto das tarefas foi
eficiente durante os testes com usurios.
Essa anlise foi possvel com a realizao de um processo de transcrio manual, ou
seja, ouvindo-se os udios gravados e comparando-se com o texto gravado nos logs, o qual
representa o que foi entendido pelo sistema e como essa entrada foi interpretada pelo
reconhecedor.
de voz cumpriu com sua tarefa de reconhecer a entrada fornecida
vezes, como pode ser visto na
reconhecimento
casos de erro e a preveno destes erros.
foram falas fora do contexto, ou seja, falas que no
proposta. Outros 3% foram falas fora da gramtica, ou seja, falas dentro do contexto da
tarefa, mas fora do alcance da gramti
frase, e
na na Figura
end-pointer
usurios e 9% de rudos no ambiente em que ocorreu a interao
grfico da
reconhecedor.
Nessa anlise
, como pode ser visto na
Figura
Vale lembrar que o objetivo nos ECs no foi o de avaliar e melhorar o software de
reconhecimento de voz
Em 14% das interaes ocorreram erros de reconhecimento de voz, dos quais
mas fora do alcance da gramti
Sobre os erros do reconhecedor de voz,
4% erros de entendimento. Destes 8%
Figura 54 54, a maioria, ou seja, 73% ocorreram devido a problemas com o
pointer, que estabelece o incio e o fim de uma fala, 18% de falas muito longas
grfico da Figura 55
anlise foram transcrit
, como pode ser visto na
Figura 54 - Tipos de
de voz, mas sim projetar interfaces
mas fora do alcance da gramti
, a maioria, ou seja, 73% ocorreram devido a problemas com o
, que estabelece o incio e o fim de uma fala, 18% de falas muito longas
55 55.
Captulo 7
foram transcritas as 957
Figura 54.
Tipos de erro identificados na interface de voz
, mas sim projetar interfaces
mas fora do alcance da gramtica projetada.
Captulo 7 - Anlise
137
957 falas e foi possvel identificar que
erro identificados na interface de voz
, mas sim projetar interfaces
ca projetada.
Sobre os erros do reconhecedor de voz, 4% foram de interpretao errnea de uma
4% erros de entendimento. Destes 8% de erros do reconhecedor de voz,
Anlise dos Resultados
foi possvel identificar que
, mas sim projetar interfaces que possibilit
foram falas fora do contexto, ou seja, falas que no estavam
4% foram de interpretao errnea de uma
de erros do reconhecedor de voz,
Resultados dos Estudos de Caso
foi possvel identificar que
de voz cumpriu com sua tarefa de reconhecer a entrada fornecida pelo usurio em 86% das
possibilitassem a recuperao em
estavam relacionadas com a tarefa
de erros do reconhecedor de voz,
usurios e 9% de rudos no ambiente em que ocorreu a interao, como pode ser visto no
dos Estudos de Caso
foi possvel identificar que o reconhecedor
pelo usurio em 86% das
m a recuperao em
relacionadas com a tarefa
de erros do reconhecedor de voz, apresentados
, a maioria, ou seja, 73% ocorreram devido a problemas com o mecanismo
, como pode ser visto no
dos Estudos de Caso
o reconhecedor
pelo usurio em 86% das
m a recuperao em
Em 14% das interaes ocorreram erros de reconhecimento de voz, dos quais 3% 3%
relacionadas com a tarefa
apresentados
mecanismo de de
, que estabelece o incio e o fim de uma fala, 18% de falas muito longas dos
, como pode ser visto no
abordagem proposta nesta tese durante as fases do projeto foi eficiente e a maioria dos
problemas foram corrigidos nas outras atividades do ciclo at o momento dos Testes com
Usurios. Alm disso, a taxa de recuperao de erros tambm mostra que
neste trabalho para
casos de erro, ou seja 134 casos ou 14% do total de interaes,
recuperar de um erro de reconhecimento e completar a taref
apresentado no grfico da
A pouca taxa de erros na gramtica da interface de voz sugere
neste trabalho para
apresentado no grfico da
Figura
neste trabalho para preveno e
apresentado no grfico da Figura
Captulo 7
Figura 55 - Subdiviso dos tipos de erros
preveno e recuperao de erros foram eficientes, pois
Figura 56.
Captulo 7 - Anlise
138
Subdiviso dos tipos de erros
recuperao de erros foram eficientes, pois
recuperar de um erro de reconhecimento e completar a tarefa
casos de erro, ou seja 134 casos ou 14% do total de interaes, os usurios
a em at 3 tentativas
dos Estudos de Caso
A pouca taxa de erros na gramtica da interface de voz sugere que o uso da
Usurios. Alm disso, a taxa de recuperao de erros tambm mostra que as tcnicas usadas
recuperao de erros foram eficientes, pois em em 74% dos
os usurios consegu
em at 3 tentativas, como
dos Estudos de Caso
o uso da
as tcnicas usadas
74% dos
uiram se
, como
total de interaes analisadas das tarefas foram completadas com dados errados, ou seja fora
do contexto do protocolo de Testes com Usurios, pois 26% dos casos de erro, ou seja
interaes de 957 no total, foram completa
aplicao da estratgia de recuperao de erros, a taxa de sucesso aumentou de 86% para
96%.
Figura
sincronismo com a interface de voz, ele
;QACOOK
Pode-se ainda inferir
Figura 57 - Taxa de Recuperao de Erros em relao ao total de interaes analisadas
Verificou-se tambm que
;QACOOK /)* "/-!# /)* "/-!#
Figura
se ainda inferir pelas
Taxa de Recuperao de Erros em relao ao total de interaes analisadas
se tambm que
/)* "/-!#
Captulo 7
Figura 56 - Taxa de Recuperao de Erro
pelas Figura
se tambm que quando o usurio interage com a interface grfica em
<KP?H BC 3?H?O
2NNKO
Captulo 7 - Anlise
139
Taxa de Recuperao de Erro
Figura 56 e Figura
interaes de 957 no total, foram completadas com dados incorretos
quando o usurio interage com a interface grfica em
sincronismo com a interface de voz, ele geralmente
<KP?H BC 3?H?O 0,. "(''!#
2NNKO (*+ "(+!#
2NNKO 9CAQLCN?BKO
2NNKO 6XK 9CAQLCN?BKO
Figura 57 57 que apenas uma taxa de 3,65% do
das com dados incorretos
geralmente usa os termos que esto escritos na
0,. "(''!#
(*+ "(+!#
2NNKO 9CAQLCN?BKO
2NNKO 6XK 9CAQLCN?BKO
que apenas uma taxa de 3,65% do
das com dados incorretos. Percebe
usa os termos que esto escritos na
2NNKO 9CAQLCN?BKO 00 "('$+!#
2NNKO 6XK 9CAQLCN?BKO *, "*$-!#
;QACOOK ?LZO
9CAQLCN?YXK BC CNNKO-
0))
dos Estudos de Caso
Percebe-se que aps a
00 "('$+!#
*, "*$-!#
;QACOOK ?LZO
0)) "0-!#
dos Estudos de Caso
do contexto do protocolo de Testes com Usurios, pois 26% dos casos de erro, ou seja 35 35
se que aps a
140
interface grfica para elaborar a sua fala. Esse um dos princpios definidos no DR capturado
e armazenado pela abordagem proposta de acordo com a teoria da lingstica (ALMOR,
1999) que afirma que mais fcil se referir a uma entidade quando ela est inserida no
dilogo pois o usurio evita o esforo de rearticular uma frase para se referir entidade e
mais fcil usar um substantivo que est visualmente acessvel do que criar uma sentena para
se referir entidade.
Esse tipo de anlise no seria possvel utilizando-se somente a avaliao heurstica e
seria realizada com uma amostra pequena de usurios caso os Testes com Usurios fossem
realizados sem o auxlio do MMLOG.
Outro ponto interessante identificado nos ECs foi a recuperao de erros de
reconhecimento de voz por meio do uso da interface grfica tanto para usurios no nativos
em ingls como para ambientes com rudo ou problemas no software de reconhecimento de
voz quando este falha na tarefa de obter uma interpretao no que foi falado (erros ou
abrangncia limitada das gramticas projetadas para a interface falas fora da gramtica ou
fora do domnio da tarefa) ou quando este interpreta de forma errnea a fala do usurio, por
exemplo, durante o reconhecimento de uma cadeia de dgitos, a troca de five por nine
devido semelhana na fontica das duas palavras, ou at mesmo por erros no mecanismo de
end-pointer que responsvel por segmentar o sinal de entrada de udio, truncando a fala do
usurio e impossibilitando o seu reconhecimento.
Outro fato que pde ser percebido analisando-se os grficos gerados pelo MMLOG
que a preciso do reconhecedor de voz est diretamente associada com rudo no ambiente,
velocidade da fala, frustrao do usurio no nativo e uso de frases muito grandes. No caso
da frustrao, que subjetivo, verificou-se que quando o usurio tem sua fala rejeitada na sua
primeira tarefa as falas posteriores incluem interjeies que demonstram frustrao e
descontentamento com o uso da voz e ele tende a usar os comandos grficos para realizar
tarefas mais difceis como falar uma cadeia de dgitos ou falar uma data (para o caso dos no
nativos).
7.4 Estratgia de comandos universais
Correlacionando os resultados obtidos neste trabalho com os dados de projetos de
interfaces de voz (COHEN; GIANGOLA; BALOGH, 2004), percebeu-se que houve pouco
uso do mecanismo de comandos universais (comandos globais que permitem: obter ajuda,
repetir algo que no foi entendido pelo usurio, desfazer uma ao ou tarefa, entre outros).
141
Isso se deveu ao fato de que, durante a atividade de anlise de tarefas, as interfaces de voz
foram projetadas com informaes complementares interface grfica, que apresenta a
informao de maneira resumida. Dessa forma, o usurio utilizou poucas vezes o mecanismo
de ajuda na interface grfica diminuindo assim a carga necessria no seu sistema cognitivo
para compreender e utilizar a interface.
Os comandos repetir e desfazer tambm foram usados com pouca frequncia nas
interfaces multimodais avaliadas, pelo fato de que a interface grfica funciona como um
mecanismo de resumo do que foi utilizado como prompt de voz para uma determinada tarefa
e pelo fato de que o usurio consegue visualizar as tarefas anteriores, no sendo necessrio
pedir para voltar ou repetir.
No Quadro 12 so apresentados os comandos que estavam disponveis aos usurios
nos estudos de caso e o nmero de vezes que eles foram utilizados. O total de falas coletadas
foi de 26010 e o nmero de interaes foi de 1530. Verifica-se que a taxa de utilizao desses
comandos inferior a 1% nas interfaces multimodais estudadas, enquanto que nas interfaces
de voz essa taxa est prxima dos 7%.
Quadro 12 - Utilizao de comandos universais nos estudos de caso
EC1 EC2 EC3
Comandos Total de falas = 4571 Total de falas = 19855 Total de falas 1584
Ajuda 5 19 2
Repetir 1 3 0
Menu Principal 6 23 1
Desfazer 1 5 0
Total 0,28% 0,25% 0,19%
7.5 Estratgia de confirmao de entradas incertas
As interfaces multimodais so probabilsticas e as entradas do usurio tm que ser
interpretadas por reconhecedores, como na tecnologia de reconhecimento de voz, na qual as
dificuldades de reconhecimento so intensificadas pelas condies sob as quais o sistema
opera (BOURGUET, 2008).
A estratgia de confirmao utilizada para garantir que as entradas incertas das
interfaces probabilsticas possam ser simplificadas nas interfaces multimodais, atrasando a
confirmao para depois que as entradas de voz ou gestos forem combinadas em um
comando completo multimodal (MCGEE; COHEN; OVIATT, 1998).
O mecanismo de confirmao, muito usado nas interfaces de voz, tambm pode ser
simplificado nas interfaces multimodais pelo fato de que o sincronismo das interfaces de voz
142
e grfica funciona como um mecanismo de confirmao automtica, j que o usurio
consegue ver em tempo real o que ele acabou de fornecer como entrada de voz, e assim
utilizar o modo grfico para apontar um erro. A correo pode ser feita com o uso de ambas
as modalidades.
Nos estudos de caso percebeu-se que os usurios tentam corrigir usando a mesma
modalidade em que houve o erro, e caso o erro ainda persista, ele troca de modalidade j no
segundo erro, como pode ser observado no Quadro 13. Pode-se observar que o usurio
daniel ao interagir com a tarefa de informar o nmero do carto de crdito (CCNum),
utilizou a interface de voz nas duas primeiras interaes, nas quais ocorreram erros de
NoMatch, ou seja, a fala do usurio no confere com os dados presentes na gramtica. Na
terceira tentativa o usurio trocou de modalidade, informando o nmero do carto pela
interface grfica, completando sua tarefa com sucesso.
Quadro 13 - Trecho do MMLOG que apresenta mudana de modalidade aps um erro
SsID Modalida
de
Usurio Tarefa Interpretao Confian
a
Evento Tempo
96bef... Voz daniel CCNum 5874.3500.4175.29
00
0.3 NoMatch1 5.6089
96bef... Voz daniel CCNum 9874.3500.0079.25
00
0.2 NoMatch2 6.8900
96bef... Grfica daniel CCNum 5874.3500.0072.29
00
1.0 TaksCompleted 13.518
Nas pesquisas de interfaces de voz recomenda-se o uso de trs tentativas seguidas de
duas confirmaes para obter um dado do usurio. Caso no haja sucesso no 3 prompt, ele
deve ser ajudado de outra maneira ou ser transferido para um atendente humano no caso de
sistemas de call center. Essa uma grande vantagem das interfaces multimodais, pois o
usurio consegue ter a possibilidade de usar uma outra modalidade para fornecer a entrada
que esperada em uma tarefa. Esse comportamento foi verificado aplicando-se regras de
associao (AGRAWAL; IMIELINSKI; SWAMI, 1993), como apresentado na sequncia.
7.6 Regras de associao para a identificao de padres de interao
Uma regra de associao uma regra da forma A$B na qual A e B so conjuntos de
itens da base de dados, e de taI Iorma que A B O. As duas medidas cIassicas para a
gerao de regras de associao so suporte e confiana.
O valor do suporte mede a probabilidade conjunta de ocorrncia de um conjunto de
itens em uma base de dados, ou seja, sup(A$B) = n(A U B) / N, na qual n(A U B) o
nmero de transaes nas quais os itens em A e em B ocorrem juntos, e N o nmero total de
143
transaes. J a confiana indica a probabilidade de ocorrncia de A e B dado que A ocorreu,
ou seja, conf(A$B) = n(A U B) / N (A).
Como foi exemplificado anteriormente, durante as iteraes do usurio com o
sistema, foram criados logs das aes dos usurios e das respostas do sistema aplicando-se a
tcnica MMLOG. Foram criados dois tipos de arquivos de logs: um mantendo todas as
iteraes de cada usurio e respostas do sistema em uma nica tupla da base de dados, que
ser tratado como BASE-1, e outro arquivo contendo cada ao do usurio e a respectiva
resposta do sistema um uma nica tupla da base de dados, que ser nomeado BASE-2.
A BASE-1 contm 1.530 transaes, ou seja, houve 1.530 registros de interao com
um prottipo gerado pelo MMWA-ae salvos na base de dados. Cada interao neste caso
representa um conjunto de tarefas que foi realizado por um usurio, seguindo o protocolo de
testes proposto pelo projetista.
A BASE-2 contm 26.010 transaes, ou seja, houve 26.010 interaes com
elementos especficos de interface do prottipo gerado pelo MMWA-ae. Cada interao neste
caso representa uma tarefa especfica que foi realizada por um usurio seguindo o protocolo
de testes proposto pelo projetista. Ou seja, ambas as bases so iguais, mas a BASE-2 permite
uma anlise mais detalhada da interao com uma tarefa especfica.
Como o nmero de transaes na BASE-2 consideravelmente maior e o nmero de
itens nas transaes consideravelmente menor, h a necessidade do suporte ser menor. Por
exemplo, em uma base com 10 transaes, com suporte de 50%, os itens poderiam coocorrer
em 5 transaes, o que no seria muito difcil de acontecer. J em uma base com 1.000
transaes, os itens teriam que coocorrer em 500 transaes, o que j seria mais improvvel
apesar de mantida a proporo de 50%. Alm disso, quanto mais itens existirem em uma
mesma transao, maior a chance de um item coocorrer com outro item. Quando h
transaes com menos itens, a chance de coocorrncia menor, portanto o suporte mnimo
deve diminuir tambm.
Com o uso de associaes, foi possvel extrair relaes do tipo qual a coocorrncia e
com que confiana o usurio utiliza as modalidades grfica e de voz ou ambas em conjunto
em uma mesma interao, ou ainda, quando o usurio utiliza a interface de voz, qual o tipo de
erro mais frequente, em que parte da interface o erro ocorre e como feita a recuperao do
erro.
Para a obteno das regras de associao da base de logs foi utilizada a
implementao de Christian Borgelt (2004) para encontrar regras de associao utilizando o
algoritmo APRIORI (AGRAWAL; SRIKANT, 1994). Como suporte mnimo e confiana
144
mnima foram utilizados os valores 50% e 70% respectivamente, ou seja, s sero obtidas
regras cujos itemsets coocorram no mnimo em 70% das transaes e que a ocorrncia de um
determinado itemset implica a ocorrncia de um itemset em pelo menos em 50% das vezes.
Algumas das regras obtidas utilizando a BASE-1 esto ilustradas no Quadro 14.
Quadro 14 Exemplos de Regras da BASE-1
Regras Suporte Confiana
$ VOICE 85.9 85.9
$ GRAPHICAL 87.3 87.3
VOICE $ GRAPHICAL 74.6 86.9
GRAPHICAL $ VOICE 74.6 85.5
VXML ERROR $ GRAPHICAL 50.7 92.3
VOICE $ name GRAPHICAL 71.8 98.1
Pode-se notar que na grande maioria das iteraes o usurio opta por usar as
modalidade voz e grfica em conjunto, ou seja, em 74.6% das interaes, utilizou-se da
multimodalidade, sendo que a ocorrncia do uso de voz implica a ocorrncia do uso da
interface grfica com 86.9% de confiana, e o uso da modalidade grfica implica o uso de
voz com 85.5% de confiana (Apesar de em 87.3% das vezes o usurio utilizar a modalidade
grfica, em 74,6% houve a coocorrncia em a modalidade grfica e a de voz).
Tambm foram obtidas regras utilizando a BASE-2, ilustradas no Quadro 15. O
intuito de utilizar esta base identificar os erros mais comuns com o uso da modalidade voz.
Para este tipo de arquivo foi utilizado um suporte mnimo de 2% e uma confiana mnima de
10%. O erro mais comum identificado com os limiares de suporte e confiana utilizados foi a
identificao do nome quando se utiliza a interface de voz.
Quadro 15 - Regras da BASE-2
Regras Suporte Confiana
VXML ERROR $ name 3.3 33.6
name $ VXML ERROR 3.3 32.8
Esse tipo de erro ocorre devido a grande diversidade de nomes e complexidade da
gramtica de voz. Nesse caso, a recuperao de erro mais comum
realizada trocando-se para a modalidade grfica aps uma segunda tentativa por voz. Em
71.8% das interaes grficas com a interface de captura de nomes
houve uma interao por voz anterior com 98.1% de confiana como pode ser verificado na
ltima linha do Quadro 14.
145
7.7 Identificao das propriedades CARE nos logsgerados pela tcnica
MMLOG.
Como foi apresentado na Seo 4.7.2, o mecanismo de gerao e anlise automtica
de log em Interaes Multimodais Web (MMLOG) uma tcnica utilizada para realizar
testes com usurios na atividade de avaliao de usabilidade da MMWA.
Como resultado da execuo do MMLOG um arquivo de log gerado, contendo
informaes de interaes com cada um dos elementos de interface (widgets).
Pelo fato de que as propriedades CARE podem ser descritas usando uma notao
matemtica, possvel consultar o MMLOG procurando por uma propriedade especfica, ou
por erros relacionados a uma propriedade que no tenha sido considerada, mas que utilizada
pelos usurios, gerando um problema de interao.
As frmulas em notao matemtica adaptadas de (COUTAZ et al., 1995; KAMEL;
AIT AMEUR, 2007) so apresentadas a seguir:
(1)
$
#
$ $ $
$ $
(2)
$ $ $ $ $ $
(3)
$ $
(4)
$ $
Onde:
" t = tarefa atual.
" t= prxima tarefa.
" tw = (tempo final tempo inicial).
" M = conjunto de modalidades (
$
.
" Card = cardinalidade de M.
" Reach = funo que descreve o fluxo entre as tarefas t e t.
Na Seo 5.4, foi apresentado um exemplo de propriedade CARE que gerou um
problema de usabilidade, e como as informaes contidas no modelo e atualizadas com a
aplicao do MMLOG contriburam para a soluo deste problema, pois o usurio utilizou
complementaridade, em sua interao, e o sistema somente entendia redundncia e
equivalncia.
146
Essa identificao de problema possvel, analisando-se o log gerado. No exemplo do
Quadro 16 percebe-se que houve um evento de nomatch na interface de voz seguido de uma
interao com a interface grfica que completou a tarefa. Nesse caso o usurio ouviu um
prompt de erro que poderia ser evitado.
Aps a transcrio da fala que gerou o evento de erro, possvel aplicar a frmula (1)
e identificar que se a propriedade complementaridade fosse utilizada, a tarefa teria sido
completada com sucesso, pois a utilizao de duas modalidades para a mesma tarefa resultou
na finalizao bem sucedida de uma tarefa.
Essa informao fica disponvel no modelo de tarefas e o projetista pode aceitar a
sugesto diretamente na interface do MMWA-ae.
Quadro 16 - Exemplo de erro que pode ser corrigido com o uso das propriedades CARE
SsID Modalidade Usurio Tarefa Interface Interpretao Confiana Evento Tempo
44xqs... Voz vandre ChoosePlace1 choose_place_2 - - NoMatch1 23.40
44xqs... Grfica vandre ChoosePlace1 place2Input CentralPark - TaksCompleted 24. 00
Mesma interao, aps incluso da propriedade Complementaridade:
03qwe... Voz vandre ChoosePlace1 choose_place_2 Select this 1.0 Recognition 21.20
03qwe... Grfica vandre ChoosePlace1 place2Input CentralPark - TaksCompleted 22. 44
7.8 Documentao e processo de captura, armazenamento e recuperao
de DR
O intuito de capturar DR nos estudos de caso foi criar uma base de informaes
contendo o raciocnio das decises de projetos obtidas durante o projeto de artefatos. O
entendimento da justificativa das decises de projeto feitas ao longo do processo de criao
das interfaces necessrio para compreender, recriar, reutilizar ou modificar o projeto.
O formato de representao de DR importante para certificar que o raciocnio
capturado ser utilizado eficientemente em outros projetos. A abordagem que foi utilizada
para representar o DR foi a representao em pginas Wiki de forma que o DR pudesse ser
capturado e armazenado usando os mtodos e mdias tradicionalmente aceitos para a
representao do conhecimento de maneira colaborativa.
As pginas da Wiki so criadas automaticamente pelo MMWA-ae e organizadas de
acordo com o projeto que est sendo desenvolvido, e de acordo com a atividade da
abordagem que est sendo utilizada no momento. A ferramenta tambm oferece suporte para
147
que o DR seja coletado em um formato pr definido de modo que possa ser interpretado e
entendido por ferramentas computacionais e um suporte recuperao da informao possa
ser fornecido.
A vantagem dessa abordagem que o mtodo utilizado para capturar e recuperar
informaes de DR semiautomatizado. A informao tambm pode ser acessada pela
pgina principal da Wiki, em uma maneira convencional, ao invs de usar a ferramenta de
autoria, de acordo com um modelo de pgina predefinido (namespace). Isso possvel, pois o
MMWA-ae cria automaticamente uma pgina com links para os DR, organizados por projeto
e atividade da MMWA.
Como resultado, o MMWA-ae facilita e promove a recuperao de DR para verificar
se as decises de projeto e o produto refletem o que foi definido na atividade de especificao
do MCI. Da mesma forma, o DR foi utilizado nos ECs para avaliar as vrias alternativas de
projeto discutidas no processo de projeto na atividade de Anlise das Solues da MMWA.
Foi verificado que o design rationale tambm importante para ajudar a determinar
as mudanas que so necessrias para alterar o projeto nas fases de manuteno e tambm
para determinar como um determinado artefato pode ser reutilizado em um novo projeto com
a MMWA.
Alm disso, o DR foi utilizado como um recurso para ensinar novos membros da
equipe de projeto que no eram familiares com o projeto ou com a tecnologia e as linguagens
de programao multimodais a aprender sobre as melhores prticas neste contexto. Da
mesma forma, promoveu a comunicao entre a equipe de projeto facilitando a troca de
informaes entre as pessoas que estavam envolvidas no processo, ajudando-os a obter um
projeto mais organizado de maneira mais rpida e a verificar as decises tomadas no processo
de projeto.
Em complemento, favoreceu e facilitou a criao da documentao do produto, que
envolvia reunies de projeto, discusses de alternativas de projeto, raciocnio das solues,
melhor entendimento do fluxo de atividades e tarefas, entre outros, devido s caractersticas
do design rationale para documentar as atividades de projeto como um todo.
7.9 Identificao de padres de projeto a partir de DR
Outro resultado significativo obtido foi uma tcnica para identificao de padres de
projeto a partir do DR capturado nos estudos de caso. Com base no DR coletado em vrios
projetos, foi criada uma tcnica que ajuda na identificao de um padro de projeto, tambm
148
conhecido como uma fonte de solues comprovadas para um problema recorrente em um
contexto conhecido (NETO et al., 2006).
Na Figura 58 ilustrado como um padro de projeto pode ser identificado com base
em caractersticas do DR como questes, posies e argumentos e algumas atividades
agregadoras (atividades guarda-chuva) que so aplicadas em todo o processo da MMWA para
a identificao do raciocnio, como as propriedades CARE, padres de interao e
preferncias do usurio, bem como as heursticas, princpios e checklists que ajudam na
formalizao dos padres de projeto.
Essa tcnica fundamenta-se em questes sobre problemas repetidos que so
encontrados no DR, os quais so resumidos como o problema, posies recorrentes apoiadas
por argumentos bem formulados, o que leva s foras e todo o raciocnio capturado, que
pode ser derivado em uma soluo.
Figura 58 - Estrutura para identificao de padres de projeto
O padro Large Group Selection, Apndice A, foi identificado utilizando como base o
DR dos ECs armazenado na DokuWiki.
O Problema, Como apresentar um grande grupo de informaes de entrada para o
usurio na interface multimodal?, foi identificado a partir de diferentes Questes em
diversos artefatos do Modelo de Tarefas, como foi apresentado na Figura 36 da seo 5.4. As
Foras ou motivaes so um resumo dos Argumentos utilizados pelos projetistas para se
149
chegar a uma concluso. A Soluo e os Exemplos so obtidos das Posies dos projetistas
que levaram s Solues finais dos DR e o Contexto Resultante foi obtido de Questes que
foram geradas a partir da questo principal.
7.10 Consideraes quanto reutilizao de cdigo
A reutilizao de cdigo pode ocorrer de diversas maneiras, por exemplo, por meio de
gerao de cdigo fonte ou por herana, sendo assim difcil determinar qual oferece maior
vantagem. Existem diferentes mtricas para reutilizao, como as estruturais, econmicas e
de repositrio (LUCREDIO et al., 2008), mas neste trabalho sero considerados os aspectos
estruturais, com as mtricas de taxa de reutilizao desejada e no desejada.
Para obter a taxa de reutilizao e verificar que o reuso foi promovido pela MMWA-
ae, a seguinte frmula foi definida e utilizada:
(1) ReutilizationRate = (LOCreused + LOCWhiteBox LOC of non-desired methods) /
LOC total
Onde:
" LOCreused: LOC gerado pelo MMWA-ae. Inclui a implementao de gramticas,
cdigo CSS, interface X+V, sugestes obtidas dos DRs e dos padres de projeto
identificados neste trabalho.
" LOCWhiteBox: LOC gerado pelo MMWA-ae, tais como, a definio de mtodos
e templates que devem ser completados pelo desenvolvedor. Isso requer que o
desenvolvedor entenda o que deve ser feito para us-lo de maneira eficiente. Por
essa razo o uso do DR importante para explicar o como e o porqu.
Exemplo: o MMWA-ae gera a definio de funes ECMAscript para permitir
validao, verificao, etc. Os mtodos utilizado nas classes de avaliao de
usabilidade tambm podem ser estendidos.
" LOC of non-desiredmethods: LOC que deve ser removido do produto final, por
no ter serventia.
" LOC total: o nmero total de linhas de cdigo gerado pela MMWA-ae.
importante mencionar que o mecanismo de gerao de cdigo do MMWA-ae segue
as referncias de implementao dos DR e padres de projeto, evitando assim a gerao
intensa de cdigo, geralmente produzida por geradores de cdigo convencionais. O
150
"LOCWhiteBox" foi considerado porque acredita-se que essa a contribuio mais valiosa
do gerador de cdigo, uma vez que fornece aos desenvolvedores uma boa percepo sobre a
forma de complementar os mtodos para obter um cdigo de boa qualidade e, assim,
aumentar a usabilidade da interface como um todo.
No MMWA-ae foram includos at o momento da escrita da tese os DRs relacionados
com usabilidade/acessibilidade, padres de projeto, prompts de voz, gramticas de voz,
cdigo fonte X+V, sincronizao e documentao.
Esses DR foram embutidos no cdigo gerado, ou seja, o projetista seleciona uma
opo no MMWA-ae e o cdigo gerado automaticamente.
Apenas os DR relacionados com a arquitetura de projeto e a plataforma em que o
reconhecedor de voz funciona no foram considerados no cdigo do MMWA-ae.
Aplicando-se a frmula de reutilizao para o cdigo gerado no ltimo estudo de caso
com o MMWA-ae foi obtida uma taxa de reutilizao de 83% e 3,2% de reutilizao no
desejada.
Taxa de Reutilizao para o EC3 = 0,83 = 83%:
" LOCreused: 534
" LOCWhiteBox: 13
" LOC of non-desired methods: 20
" LOC total: 636
Porcentagem de mtodos no desejados = 20/636 = 3.2%
Em um outro exemplo, retirado do terceiro estudo de caso, pode-se citar o fato que o
MMWA-ae foi utilizado para gerar a interface de apresentaes para eventos, ou seja, uma
interface multimodal Web foi criada. Trs arquivos foram automaticamente criados. Pode-se
aplicar a frmula para o clculo da taxa de reutilizao para cada artefato gerado:
Uma gramtica de voz, cuja taxa de reutilizao foi igual a 100%:
o LOCreused: 59
o LOCWhiteBox: 0
o LOC of non-desired methods: 0
o LOC total: 59
151
o Non-desired methods percentage = 0%
Um arquivo X+V, cuja taxa de reutilizao foi igual a 84%:
o LOC reused: 416
o LOC criado pelo desenvolvedor: 42
o LOCWhiteBox: 23
o LOC total: 494
o Non-desired methods percentage = 2.6%
Um arquivo CSS, cuja taxa de reutilizao foi igual a 100%:
o LOC reused: 96
o LOC criado pelo desenvolvedor: 0
o LOCWhiteBox: 0
o LOC total: 96
o Non-desired methods percentage = 0%
interessante notar que no exemplo anterior a taxa de reutilizao maior do que no
primeiro exemplo e o LOC menor, ou seja, para projetos pequenos e para a gerao de
prottipos rpidos para testes de usabilidade, o MMWA-ae eficiente, principalmente se for
considerado o tempo gasto para a obteno das interfaces, conforme ser apresentado na
prxima seo.
7.11 Tempo gasto para projetar a interface e para obter o prottipo de
interface para testes com usurios.
O tempo gasto para projetar a interface uma das principais vantagens da utilizao
do MMWA-ae, uma vez que o prottipo pode ser obtido logo aps a concluso da fase de
projeto.
152
Em contraste, quando o MMWA-ae no utilizado vrias tarefas devem ser
realizadas antes da gerao do prottipo, como: consultas de DR na base de dados, discusses
em equipe para validar a implementao, rodadas de anlise de erros para corrigir problemas
de usabilidade das interfaces, criao e testes de gramticas de interfaces de voz, etc.
Outra rea de interesse o tempo utilizado para criar interfaces de voz (VUI), que foi
reduzido. O MMWA-ae oferece ao projetista um assistente para gerar todos os importantes
prompts para serem utilizados em cada interface, por exemplo, prompts iniciais, de erro,
confirmao, etc. Alm disso, escolhendo um dos padres de projeto ou um componente, por
exemplo, o componente Calendrio, a ferramenta cria automaticamente a GUI, a VUI, a
gramtica e os mecanismos para sincroniz-las, economizando tempo de desenvolvimento.
Isso tambm contribui para o aumento de usabilidade das interfaces, uma vez que o MMWA-
ae implementa a estratgia de recuperao de erros e os comandos de voz universais
(BOHUS; RUDNICKY, 2008), criando uma interface multimodal mais robusta.
Para a criao do sistema de aluguel de carros do EC3, foi considerada uma
implementao de referncia, ou seja, um dos sistemas desenvolvidos no EC1, sem o uso da
MMWA-ae.
O resultado relativo ao nmero de horas e linhas de cdigo criadas pode ser observado
no Quadro 17. Pode-se observar que o nmero de horas gastas para o desenvolvimento das
interfaces do EC3 foi aproximadamente oito vezes menor do que para o EC1, o que refora a
afirmao de que o tempo gasto para a obteno de prottipos com o uso do MMWA-ae
uma vantagem.
Quadro 17 - Tempo de desenvolvimento das interfaces geradas no EC1 e EC3
Implementao Referncia EC1 Implementao MMWA-ae EC3
Tempo de desenvolvimento
(no inclui projeto e testes)
~24hs ~3hs
LOC 575 636
Neste captulo foram apresentados os principais resultados obtidos com a avaliao e
interpretao dos dados dos estudos de caso, visando caracterizar os efeitos da aplicao da
abordagem e do ambiente de autoria propostos no projeto de interfaces multimodais Web.
Esses resultados tambm permitiram determinar as principais contribuies e as
principais limitaes deste trabalho, conforme ser discutido no prximo captulo.
Captulo 8 - Concluses
153
Captulo 8. Concluses
O principal objetivo do desenvolvimento de aplicaes multimodais possibilitar uma
maneira mais natural dos seres humanos se comunicarem com as mquinas, por meio de
interfaces mais eficientes, intuitivas, fceis de usar e, de certa forma, mais inteligentes.
No entanto, a literatura da rea mostra que a usabilidade um objetivo constante
procurado por pesquisadores e profissionais envolvidos com desenvolvimento de software,
mas at ento pouco considerada nas ferramentas de autoria de interfaces multimodais
existentes atualmente.
A percepo que a usabilidade um conceito simples de se colocar em prtica e no
requer tanto esforo nas fases de projeto e desenvolvimento, mas a sua aplicao na prtica
complexa principalmente no que tange reutilizao sistemtica e gerencivel de
conhecimento de projeto.
A reutilizao, tanto de conhecimento como de cdigo fonte, ainda apresenta
problemas, dados a complexidade do cdigo em sistemas multimodais, a falta de mecanismos
eficientes de testes de usabilidade e a dificuldade em se gerenciar a captura, o
armazenamento e a recuperao de conhecimento de projeto, tpicos que foram abordados no
texto desta tese de doutorado.
As solues, para problemas especficos, que so encontradas na literatura so difceis
de reutilizar em projetos diferentes dos propostos pelos autores. tambm difcil entender as
razes para se especificar uma determinada interface, pois nenhuma ferramenta apresenta
mecanismos para recuperar e facilitar o entendimento do raciocnio a ser utilizado na criao
de uma determinada interface. As solues apresentadas em artigos cientficos provm
solues circunstanciais empregadas em um tipo de interao particular.
As ferramentas e a tecnologia utilizadas para a criao aplicaes multimodais so
complexas e consomem muito recurso de mquina, tornando difcil a instalao e a utilizao
em projetos Web pequenos ou diferentes da proposta de uso, modalidades e dispositivos de
interao planejados pelos autores.
Alm disso, as ferramentas encontradas na pesquisa bibliogrfica apresentam
problemas de extensibilidade e, as que so baseadas em modelos, dificilmente incluem
informaes de usabilidade das interfaces em seus modelos.
154
Neste captulo so resumidas as contribuies apresentadas nesta tese de doutorado
para o projeto, desenvolvimento e avaliao de interfaces multimodais Web, no que tange:
" Contribuies tericas e conceituais, uso e validao dos conceitos que circundam o
problema atacado;
" Contribuies metodolgicas aos projetistas com a finalidade de prover auxlio na
manipulao dos conceitos introduzidos neste trabalho;
" Suporte ferramental expressando como as contribuies metodolgicas podem ser
apoiadas por um software.
8.2 Contribuies
Nesta tese foram discutidas propostas e idias para resolver parte dos problemas
abordados anteriormente sobre o projeto e desenvolvimento de interfaces multimodais Web.
Estudos e pesquisas nas principais fontes de artigos cientficos da rea foram
realizados para a definio de uma abordagem centrada no usurio e um ambiente de autoria
composto por um modelo de tarefas visando tambm guiar o projetista e o desenvolvedor
deste tipo de interface desde as atividades iniciais de levantamento de requisitos at a fase de
avaliao de usabilidade.
Assim, pode-se identificar as seguintes contribuies, resultados deste trabalho:
" Uma abordagem centrada no usurio, sistemtica, contendo atividades, entradas e
sadas que descrevem as tarefas necessrias para a obteno de uma interface
multimodal com usabilidade.
" Definio de um mecanismo de avaliao de usabilidade automtica contendo
mtodos analticos e empricos, que se conectam a um modelo de anlise de
tarefas, por meio do relacionamento de lista de verificao (checklists), princpios
e heursticas e com o auxlio de dados obtidos com a anlise de interaes com
usurios reais.
" Desenvolvimento e utilizao de uma tcnica para a utilizao de sistemas Wiki
para a coleta, armazenamento e recuperao de DR, para que o conhecimento de
projeto seja armazenado estruturadamente de uma maneira no intrusiva, de forma
que futuros projetos possam se beneficiar, diminuindo o tempo necessrio para a
criao de interfaces multimodais Web.
" Ambiente de autoria e modelo de tarefas que permitem a gerao de prottipos de
interfaces.
155
" Diretrizes para promover a reutilizao de cdigo e DR e a criao de um
mecanismo automtico de sugestes de correo de problemas de usabilidade,
fundamentado no modelo de tarefas proposto nesta tese.
" Identificao e formalizao de padres de projeto especficos para interfaces
multimodais Web.
" Elaborao de um material de treinamento, um relatrio tcnico e de um curso
sobre Interfaces Multimodais Dinmicas, que podem vir a ser reaproveitados em
cursos de extenso, mini cursos, workshops e tutoriais relacionados aos principais
temas da tese.
" Publicao de artigos cientficos e apresentaes em conferncias importantes
para a rea de pesquisa.
" Orientao de dois alunos de graduao que utilizaram esta pesquisa em suas
monografias de projeto final na disciplina de Projeto/Estgio (SCC298/299) do
ICMC/USP.
8.3 Lies aprendidas
Em 2006, no incio desta pesquisa, era difcil encontrar ferramentas para o projeto de
interfaces multimodais Web disponveis para acesso e avaliao. Todo o conhecimento era
divulgado em artigos cientficos, e at mesmo os dispositivos para acessar essa tecnologia
no eram facilmente encontrados.
Hoje em dia, com a disseminao de dispositivos como o celular IPhone e o tablet
IPad da Apple Inc, o videogame Wii da Nintendo
e o console Kinect para Xbox da

Microsoft
, e com a criao de mecanismos para acesso e simulao de testes em dispositivos

remotos para desenvolvedores, como o Device Anywhere
12
, novas aplicaes multimodais
surgem a cada dia e novas pesquisas na rea, incluindo novas ferramentas e abordagens, vo
sendo divulgadas no ambiente acadmico e comercial.
Alm disso, as empresas comearam a fornecer aos desenvolvedores, os kits de
desenvolvimento de software (SDK), com o objetivo de permitir que qualquer pessoa em
qualquer lugar possa criar um software para ser executado em um determinado dispositivo
utilizando a sua tecnologia. Isso d s empresas um grande diferencial competitivo, uma vez
que mais produtos so lanados com a sua tecnologia ou mais dispositivos da empresa so
vendidos por causa das funcionalidades que eles oferecem.
12
http//www.deviceanywhere.com/
156
Outra caracterstica importante do mercado atualmente o conceito de software como
servio, do ingls Software As A Service (SAAS), que um instrumento mercadolgico para
fornecer um software, em forma de um servio ou prestao de servios. O software
executado em um servidor, no sendo necessrio instalar o sistema no computador do cliente,
bastando acess-lo pela Internet. Como exemplo, o Google-Docs
13
oferece um pacote de
programas similares ao pacote MS Office da Microsoft.
A experincia adquirida no ambiente industrial pelo doutorando tambm um ponto
interessante para ser analisado, pois muitas das ideias aplicadas no trabalho de doutorado
surgiram de necessidades reais de clientes e at mesmo a escolha das tecnologias e das
atividades usadas neste trabalho so utilizadas em projetos reais.
De igual importncia, pode-se citar as atividades acadmicas, como orientao de
alunos de graduao e seminrios apresentados sobre o tema da tese que contriburam muito
para o crescimento intelectual e profissional do doutorando.
Dessa forma, pode-se dizer que essas caractersticas aqui mencionadas, bem como as
particularidades da tecnologia do contexto mercadolgico em que o trabalho est inserido
contriburam para a criao da MMWA e da MMWA-ae.
A validao do trabalho foi alcanada aplicando-se o mtodo estudo de caso, cujo
objetivo principal foi mostrar a viabilidade da abordagem proposta e as vantagens do
ambiente de autoria desenvolvido e do uso de DR no processo como um todo. No Captulo 6
apresentaram-se o planejamento, a definio e a execuo dos estudos de caso e foram
identificadas as principais hipteses que foram exploradas em detalhes no Captulo 7.
Cabe ressaltar que a diversidade de interfaces multimodais desenvolvidas e o fato do
MMWA-ae ter sido projetado para ser reutilizvel, extensvel, adaptvel e modular so
resultados importantes obtidos para que ele possa ser continuamente evoludo e possa ser
utilizado em projetos no ambiente industrial.
8.4 Publicaes resultantes do trabalho realizado nesta tese
Conforme foi citado na Seo 8.2, foram publicados trabalhos relacionados ao tema
desta tese. As publicaes esto relacionadas com a linha do tempo apresentada na Seo 6.3
e que est complementada a seguir, na Figura 59.
13
http://docs.google.com
157
Como pode-se observar, para cada ciclo definido (Pesquisa Bibliogrfica, Abordagem
e Ferramenta) foram publicados artigos que divulgam os resultados de cada atividade e
perodo de tempo.
Figura 59 - Linha do tempo das atividades realizadas no doutorado e publicaes
A seguir, esto listadas as publicaes realizadas no perodo do doutorado:
Captulo de livro publicado:
" TALARICO NETO, A. ; Fortes, R.P.M . Interfaces Multimodais Dinmicas
Utilizando J2EE. In: Marcos Roberto da Silva Borges e Jos Gonalves Pereira Filho.
(Org.). XIV SIMPSIO BRASILEIRO DE SISTEMAS MULTIMDIA E WEB:
WEBMEDIA 2008: MINICURSOS. 14 ed. VILA VELHA: Sociedade Brasileira de
Computao, 2008, v. 1, p. 1-48.
Trabalhos completos publicados em anais de congressos:
" TALARICO NETO, A., Fortes, R.P.M. Improving multimodal interaction design with
the MMWA authoring environment In: SIGDOC 2010, 2010, So Carlos. ACM
International Conference on Design of Communications. New York: The Association
for Computer Machinery, 2010. v.1. p.151 - 158
" TALARICO NETO, A. ; Fortes, R.P.M ; RESENDE, S. ; ROSSI, R. . MMWA-ae:
boosting knowledge from Multmodal Interface Design, Reuse and Usability
Evaluation. In: The 22nd International Conference on Software Engineering &
Knoledge Engineering., 2010, San Francisco. SEKE 2010 - The 22nd International
4
W
X
Y
H
S
W
W
S
F
V
I
?
I
G
S
R
L
I
G
M
Q
I
R
X
S
H
I
C
S
\
R
E
D
I
F
4
W
X
Y
H
S
W
W
S
F
V
I
M
R
X
I
V
E
i
h
S
Q
Y
P
X
M
Q
S
H
E
P
>
V
S
T
S
W
X
E
H
E
<
<
D
1
8
Q
?
H
F
D
F
A
?
Y
X
K
7
H
I
R
X
M
J
M
G
E
i
h
S
H
I
>
V
M
R
G
k
T
M
S
W
>
V
S
T
S
W
X
E
H
E
2
L
I
G
O
P
M
W
X
3
K
N
I
?
H
F
S
?
Y
X
K
B
?
O
.
P
F
R
F
B
?
B
C
O
B
?
5
5
>
.
4
2
(
%
B
W
S
H
I
3
?
<
I
P
L
S
V
M
E
W
R
E
<
<
D
1
2
V
M
E
i
h
S
H
S
<
<
6
4
I
<
<
;
=
5
4
2
)
%
B
W
S
H
E
<
<
D
1
I
1
Z
E
P
M
i
m
I
W
H
I
B
W
E
F
M
P
M
H
E
H
I
<
I
P
L
S
V
M
E
W
R
E
<
<
D
1
7
N
K
G
C
P
K
C
1
C
O
C
J
R
K
H
R
F
I
C
J
P
K
B
K
5
5
>
.
!
?
C
4
2
*
%
B
W
S
H
S
<
<
D
1
%
E
I
<
I
P
L
S
V
M
E
W
<
<
D
1
%
E
I
4
W
G
V
M
X
E
H
E
A
I
W
I
I?N"#* GQJ"#* ?EK"#* KQP"#* JKR"#* BCS"#* DCR"#+ ?@N"#+ ?EK"#+ JKR"#+ G?J"#, GQJ"#, ?EK"#, G?J"$# ?@N"$# OCP"$#
T
Y
F
P
M
G
E
i
h
S
H
I
V
I
P
E
X
l
V
M
S
X
j
G
R
M
G
S
>
Y
F
P
M
G
E
i
h
S
@
7
5
3
=
2
>
Y
F
P
M
G
E
i
h
S
D
I
F
Q
I
H
M
E
>
Y
F
P
M
G
E
i
h
S
7
6
2
>
Y
F
P
M
G
E
i
h
S
@
1
2
>
Y
F
P
M
G
E
i
h
S
@
7
5
3
=
2
>
Y
F
P
M
G
E
i
h
S
D
I
F
Q
I
H
M
E
>
Y
F
P
M
G
E
i
h
S
2
;
4
7
>
Y
F
P
M
G
E
i
h
S
@
4
9
4
>
Y
F
P
M
G
E
i
h
S
@
7
5
3
=
2
4
R
Z
M
S
H
I
1
V
X
M
K
S
T
E
V
E
8
S
Y
V
R
E
P
3
I
W
M
K
R
@
X
Y
H
M
I
W
;MRLE HS AIQTS <<D1%EI
7COMQFO? /F@HFKENWDFA? .@KNB?ECI 3CNN?ICJP?
158
Conference on Software Engineering & Knoledge Engineering. Skokie : Knowledge
Systems Intitute Graduate School, 2010. v. 1. p. 355-360.
" TALARICO NETO, A. ; Fortes, R.P.M ; Bittar, T.J. ; Felizardo K.R . Developing and
evaluating Web multimodal interfaces - a case study with usability Princpios. In:
ACM symposium on Applied Computing, 2009, Honolulu, Hawaii. Proceedings of
the 2009 ACM symposium on Applied Computing. New York, NY, USA : ACM,
2009. p. 116-120.
" TALARICO NETO, A. ; Fortes, R.P.M ; Assis, Alessandro . Avaliao de
Usabilidade em Interfaces Multimodais Web: Estudos de caso com a Abordagem
MMWA. In: XXXV CLEI - Latin American Informatics Conference, 2009, Pelotas
RS. Anais do CLEI 2009., 2009. v. 1. p. 1-10.
" TALARICO NETO, A. ; Fortes, R.P.M ; Assis, Alessandro ; Watanabe, W.M . O uso
de tcnicas automticas para Avaliao de Usabilidade no projeto de Interfaces
Multimodais Web. In: XV Webmedia - Simpsio Brasileiro de Sistemas Multimdia e
Web, 2009, Fortaleza. Anais do Webmedia 2009. Porto Alegre : SBC, 2009. v. 1. p.
1-8.
" TALARICO NETO, A. ; Fortes, R.P.M ; Assis, Alessandro ; ANACLETO, J. C. .
Design of Communication in Multimodal Web Interfaces. In: ACM International
Conference on Design of Communication, 2009, Bloomington. 27th ACM
International Conference on Design of Communication.. New York : ACM Digital
Library, 2009. v. 1. p. 81-88.
" TALARICO NETO, A. ; Bittar, T.J. ; Fortes, R.P.M ; Felizardo K.R . Abordagem
para o desenvolvimento e avaliao de interfaces multimodais Web pautada em
princpios de usabilidade. In: VIII Simpsio sobre Fatores Humanos em Sistemas
Computacionais IHC 2008, 2008, Porto Alegre. VIII Simpsio Sobre Fatores
Humanos em Sistemas. Porto Alegre: Sociedade Brasileira de Computao SBC,
2008. v. 1. p. 21-30.
Resumos publicados em anais de congressos:
" WATANABE, W.M ; TALARICO NETO, A. ; Silva Filho, A.G ; Fortes, R.P.M .
Desenvolvimento de componentes de interfaces multimodais ricas para a Web
utilizando X+V e Dojo Widgets. In: XIV Simpsio Brasileiro de Sistemas Multimdia
e Web, 2008, Vila Velha. XIV Simpsio Brasileiro de Sistemas Multimdia e Web.
Porto Alegre : SBC, 2008. v. 1. p. 97-100.
" TALARICO NETO, A. ; Fortes, R.P.M ; Silva Filho, A.G . Multimodal interfaces
design issues: the fusion of well-designed voice and graphical user interfaces. In: 26th
ACM International Conference on Design of Communication, 2008, Lisbon. 26th
ACM International Conference on Design of Communication, 2008. v. 1. p. 277-278.
Relatrio tcnico:
159
" TALARICO NETO, A. ; Fortes, R.P.M . Introduo a XHTML+Voice: Adicionando
voz s aplicaes Web. 2008.
8.5 Limitaes e oportunidades para trabalhos futuros
Durante o desenvolvimento desta tese foram identificadas algumas limitaes e
oportunidades para o desenvolvimento de trabalhos futuros que no foram investigados neste
trabalho:
" Estudos empricos: os dados obtidos com os estudos de caso e que expressam
resultados relacionados com problemas de usabilidade identificados pelo MMHE
possuem deficincias como a falta de rigor estatstico. Nos estudos de caso,
procurou-se seguir as orientaes encontradas em (NIELSEN, 2004) e avaliar
questes qualitativas embasadas em observao, entrevistas e questionrios com a
finalidade de observar o comportamento dos desenvolvedores e usurios. Assim,
pode-se obter mais resultados com a realizao de novos experimentos
quantitativos com equipes maiores ou em estudos fora do ambiente acadmico.
Por outro lado, os dados relativos coleta de logs de interao realizadas pelo
MMLOG foram analisados empiricamente, conforme explicado na Seo 7.6.
" Fuso de interfaces existentes: apesar do MMWA-ae permitir o uso de cdigo
fonte existente no desenvolvimento de novas interfaces, interessante criar um
mecanismo que importe esse cdigo, analise a sua estrutura e sugira a correo de
possveis problemas de usabilidade que possam surgir por causa da fuso das
modalidades.
" Coleta de DR e identificao de padres de projeto: nos estudos de caso
realizados, foram obtidos os seguintes nmeros em relao ao DR: 60 questes
foram criadas, 664 discusses foram obtidas para as questes e 207 consultas
foram feitas em busca de solues. Essa base de dados pode ser aumentada e mais
resultados podem ser obtidos principalmente no tocante identificao de padres
de projeto.
" Incluso de outras modalidades e outros ambientes, diferentes da Web, podem
ser realizados para validar a extensibilidade dos mdulos projetados para o
MMWA-ae.
160
" Adaptao de interfaces, para diferentes tipos de dispositivos, pode ser testada
modificando-se apenas o gerador de cdigo do MMWA-ae, pois a MMWA foi
criada com esse objetivo, tendo em vista que a especificao das tarefas e o seu
modelo no mudam e somente o cdigo que representa as interfaces concretas
deve ser modificado.
Referncias
161
Referncias Bibliogrficas
[ABRAMS, M.; et al., 1999] ABRAMS, M.; PHANOURIOU, C.; BATONGBACAL, A. L.;
WILLIAMS, S. M.; SHUSTER, J. E. UIML: an appliance-independent XML user interface
language. Comput. Netw., v. 31, n. 11-16, p. 1695-1708, 1999. ISSN 1389-1286.
[AGRAWAL, R.; IMIELINSKI, T.; SWAMI, A., 1993] AGRAWAL, R.; IMIELINSKI, T.;
SWAMI, A. Mining Association Rules between Sets of Items in Large Databases. In: PETER
BUNEMAN e SUSHIL JAJODIA, Proceedings of the 1993 ACM SIGMOD International
Conference on Management of Data, 1993. p.207-216.
[AGRAWAL, R.; SRIKANT, R., 1994] AGRAWAL, R.; SRIKANT, R. Fast algorithms for
mining association rules. p. 487-499, 1994. Disponvel em: <
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.7506 >.
[ALEXANDER, C.; ISHIKAWA, S.; SILVERSTEIN, M., 1977] ALEXANDER, C.;
ISHIKAWA, S.; SILVERSTEIN, M. A Pattern Language. New York: Oxford University
Press, 1977.
[ALLEN, J.; et al., 2001] ALLEN, J.; BYRON, D.; DZIKOVSKA, M.; FERGUSON, G.;
GALESCU, L. Toward conversational human-computer interaction. AI Mag., v. 22, n. 4, p.
27-37, 2001. ISSN 0738-4602.
[ALLEN, J. E.; GUINN, C. I.; HORVTZ, E., 1999] ALLEN, J. E.; GUINN, C. I.; HORVTZ,
E. Mixed-Initiative Interaction. IEEE Intelligent Systems, v. 14, n. 5, p. 14-23, 1999. ISSN
1541-1672.
[ALMOR, A., 1999] ALMOR, A. Noun-Phrase Anaphora and Focus: The Informational
Load Hypothesis. 1999.
[ANEGG, H.; et al., 2004] ANEGG, H.; NIKLFELD, G.; SCHATZ, R.; SIMON, R.;
WEGSCHEIDER, F. Multimodal interfaces in mobile devices the mona project MobEA
II - Emerging Applications for Wireless and Mobile Access Workshop at the 13th
International World Wide Web Conference 2004.
[BAGGIA, P. L.; et al., 2007] BAGGIA, P. L.; CARTER, J.; DAHL, D. A.; MCCOBB, G.
EMMA: Extensible MultiModal Annotation markup language. W3C Working Draft:
W3C 2007.
[BARFIELD, L.; et al., 1994] BARFIELD, L.; BURGSTEDEN, W. V.; LANFERMEIJER,
R.; MULDER, B.; JURRI; OSSEWOLD, N.; RIJKEN, D.; WEGNER, P. Interaction design
at the Utrecht School of the Arts. SIGCHI Bull., v. 26, n. 3, p. 49-86, 1994. ISSN 0736-
6906.
Referncias
162
[BELL, J., 1989] BELL, J., Ed. Doing your research project: a guide for the first-time
researchers in education and social science. London, England: Open University Press,
p.195ed. 1989.
[BERNHAUPT, R., 2008] BERNHAUPT, R. Methods for Usability Evaluation of
Multimodal Interfaces. . In: (Ed.). Tailoring Usability into Agile Software Development
Projects IGI Globa, v.1, 2008. p.96-119.
[BERNHAUPT, R.; et al., 2008] BERNHAUPT, R.; NAVARRE, D.; PALANQUE, P.;
WINCKLER, M. Tailoring Usability into Agile Software Development Projects. In: EFFIE
LAI-CHONG LAW;EBBA THORA HVANNBERG, e col (Ed.). Maturing Usability:
Springer London, 2008. p.96-119. (Human-Computer Interaction Series). ISBN 978-1-
84628-941-5.
[BERTI, S.; PATERNO, F., 2005] BERTI, S.; PATERNO, F. Migratory MultiModal
interfaces in MultiDevice environments. Proceedings of the 7th international conference on
Multimodal interfaces. Torento, Italy: ACM: 92-99 p. 2005.
[BHATTI, S., 2005] BHATTI, S. Why quality?: ISO 9126 software quality metrics
(Functionality) support by UML suite. SIGSOFT Softw. Eng. Notes, v. 30, n. 2, p. 1-5,
2005. ISSN 0163-5948. Disponvel em: < http://dx.doi.org/10.1145/1050849.1050860 >.
[BOHUS, D.; RUDNICKY, A. I., 2008] BOHUS, D.; RUDNICKY, A. I. Sorry, I Didnt
Catch That! In: LAILA DYBKJR e WOLFGANG MINKER (Ed.). Recent Trends in
Discourse and Dialogue: Springer Netherlands, v.39, 2008. p.123-154. (Text, Speech and
Language Technology). ISBN 978-1-4020-6821-8.
[BOLT, R. A., 1980] BOLT, R. A. Put-that-there: Voice and gesture at the graphics
interface. Proceedings of the 7th annual conference on Computer graphics and interactive
techniques. Seattle, Washington, United States: ACM: 262-270 p. 1980.
[BOOCH, G.; RUMBAUGH, J.; JACOBSON, I., 2005] BOOCH, G.; RUMBAUGH, J.;
JACOBSON, I. Unified Modeling Language User Guide, The (2nd Edition) (Addison-
Wesley Object Technology Series). Addison-Wesley Professional, 2005. ISBN
0321267974.
[BORCHERS, J., 2001] BORCHERS, J. A Pattern Approach to Interaction Design. John
Wiley & Sons, Inc., 2001. 268 ISBN 0471498289.
[BORGELT, C., 2004] BORGELT, C. Implementao do algoritmo Apriori (Verso 4.27)
2004.
[BOUCHET, J.; NIGAY, L.; GANILLE, T., 2004] BOUCHET, J.; NIGAY, L.; GANILLE,
T. ICARE software components for rapidly developing multimodal interfaces.
Proceedings of the 6th international conference on Multimodal interfaces. State College, PA,
USA: ACM: 251-258 p. 2004.
[BOUILLON, L.; VANDERDONCKT, J.; CHOW, K. C., 2004] BOUILLON, L.;
VANDERDONCKT, J.; CHOW, K. C. Flexible re-engineering of web sites. Proceedings of
Referncias
163
the 9th international conference on Intelligent user interfaces. Funchal, Madeira, Portugal:
ACM: 132-139 p. 2004.
[BOURGUET, M.-L., 2008] BOURGUET, M.-L. SOFTWARE DESIGN AND
DEVELOPMENT OF MUTIMODAL INTERACTION 2008.
[BURGE, J.; BROWN, D. C., 2000] BURGE, J.; BROWN, D. C. Reasoning With Design
Rationale. Artificial Intelligence in Design, 2000. p.611-629.
[BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D., 2007] BUSCHMANN, F.; HENNEY,
K.; SCHMIDT, D. Pattern-Oriented Software Architecture: A Pattern Language for
Distributed Computing (Wiley Software Patterns Series). John Wiley \\& Sons, 2007.
ISBN 0470059028.
[CARD, S. K.; NEWELL, A.; MORAN, T. P., 1983] CARD, S. K.; NEWELL, A.; MORAN,
T. P. The Psychology of Human-Computer Interaction. L. Erlbaum Associates Inc.,
1983. 469 ISBN 0898592437.
[CARROL, J., M, 1999] CARROL, J., M. Five Reasons for Scenario-Based Design. 1999.
p.3051-3051.
[CHANG, J.; BOURGUET, M.-L., 2008] CHANG, J.; BOURGUET, M.-L. Usability
framework for the design and evaluation of multimodal interaction. Proceedings of the
22nd British HCI Group Annual Conference on People and Computers: Culture, Creativity,
Interaction - Volume 2. Liverpool, United Kingdom: British Computer Society: 123-126 p.
2008.
[COHEN, M.; GIANGOLA, J.; BALOGH, J., 2004] COHEN, M.; GIANGOLA, J.;
BALOGH, J. Voice User Interface Design. Addison Wesley Longman Publishing Co.,
Inc., 2004. ISBN 0321185765.
[COHEN, P.; MCGEE, D.; CLOW, J., 2000] COHEN, P.; MCGEE, D.; CLOW, J. The
efficiency of multimodal interaction for a map-based task. Proceedings of the sixth
conference on Applied natural language processing. Seattle, Washington: Association for
Computational Linguistics: 331-338 p. 2000.
[COHEN, P. R.; et al., 1997] COHEN, P. R.; JOHNSTON, M.; MCGEE, D.; OVIATT, S.;
PITTMAN, J.; SMITH, I.; CHEN, L.; CLOW, J. QuickSet: multimodal interaction for
distributed applications. Proceedings of the fifth ACM international conference on
Multimedia. Seattle, Washington, United States: ACM: 31-40 p. 1997.
[COUTAZ, J.; et al., 1995] COUTAZ, J.; NIGAY, L.; SALBER, D.; BLANDFORD, A.;
MAY, J.; YOUNG, R. M. Four easy pieces for assessing the usability of multimodal
interaction: the CARE properties. Interact: ACM Press: 115-120 p. 1995.
[CROSS, C.; et al., 2003] CROSS, C.; AXELSSON, J.; MCCOBB , G.; RAMAN, T. V.;
WILSON, L. XHTML+Voice Profile 1.1. W3C Note 2003.
Referncias
164
[DE LUCIA, A.; et al., 2009] DE LUCIA, A.; FASANO, F.; GRIECO, C.; TORTORA, G.
Recovering design rationale from email repositories. Software Maintenance, 2009. ICSM
2009. IEEE International Conference on, 2009. p.543-546.
DECRETO N 6.523, DE 31 DE JULHO DE 2008., 2008], 2008. Disponvel em: <
http://www.planalto.gov.br/ccivil_03/_ato2007-2010/2008/Decreto/D6523.htm >. Acesso
em: November.
[DESURVIRE, H. W., 1994] DESURVIRE, H. W. Faster, cheaper!! Are usability inspection
methods as effective as empirical testing? In: (Ed.). Usability inspection methods: John
Wiley & Sons, Inc., 1994. p.173-202. ISBN 0-471-01877-5.
[DILLON, A., 2000] DILLON, A., Ed. Group dynamics meet cognition: Combining socio-
technical concepts and usability engineering in the design of information systems. The
new SocioTech: Graffiti on the long wall. London: Springer-Verlag, v.1, p.354, The new
SocioTech: Graffiti on the long walled. 2000.
[DIX, A.; et al., 1998] DIX, A.; ABOWD, G.; BEALE, R.; FINLAY, J. Human-Computer
Interaction. Prentice Hall Europe., 1998.
[DUMAS, B.; INGOLD, R.; LALANNE, D., 2009] DUMAS, B.; INGOLD, R.; LALANNE,
D. Benchmarking fusion engines of multimodal interactive systems. Proceedings of the
2009 international conference on Multimodal interfaces. Cambridge, Massachusetts, USA:
ACM: 169-176 p. 2009.
[DUMAS, B.; LALANNE, D.; OVIATT, S., 2009] DUMAS, B.; LALANNE, D.; OVIATT,
S. Multimodal Interfaces: A Survey of Principles, Models and Frameworks. In: (Ed.).
Human Machine Interaction: Research Results of the MMI Program: Springer-Verlag,
2009. p.3-26. ISBN 978-3-642-00436-0.
[DUTOIT, A. H.; et al., 2006] DUTOIT, A. H.; MCCALL, R.; MISTRIK, I.; PAECH, B.
Rationale Management in Software Engineering: Concepts and Techniques. . Springer,
2006.
[ETO, K.; TAKABAYASHI, S.; MASUI, T., 2005] ETO, K.; TAKABAYASHI, S.; MASUI,
T. qwikWeb: integrating mailing list and WikiWikiWeb for group communication.
Proceedings of the 2005 international symposium on Wikis. San Diego, California: ACM:
17-23 p. 2005.
[FIDEL, R., 1992] FIDEL, R. The case study method: a case study. . In: JACK D. &
POWELL IN: GLAZIER, RONALD R. (Ed.). Qualitative research in information
management. . Englewood, CO: Libraries Unlimited, v.1, 1992. p.238.
[FLIPPO, F.; KREBS, A.; MARSIC, I., 2003] FLIPPO, F.; KREBS, A.; MARSIC, I. A
framework for rapid development of multimodal interfaces. Proceedings of the 5th
international conference on Multimodal interfaces. Vancouver, British Columbia, Canada:
ACM: 109-116 p. 2003.
[FREIRE, A. P.; RUSSO, C. M.; FORTES, R. P. M., 2008] FREIRE, A. P.; RUSSO, C. M.;
FORTES, R. P. M. A survey on the accessibility awareness of people involved in web
Referncias
165
development projects in Brazil. Proceedings of the 2008 international cross-disciplinary
conference on Web accessibility (W4A). Beijing, China: ACM: 87-96 p. 2008.
[GAMMA, E.; et al., 1995] GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J.
Design patterns: elements of reusable object-oriented software. Addison-Wesley
Longman Publishing Co., Inc., 1995. 395 ISBN 0-201-63361-2.
[GRUBER, T. R.; RUSSEL, D. M., 1991] GRUBER, T. R.; RUSSEL, D. M. Design
Knowledge and Design Rationale: A Framework for Representation, Capture, and Use.
. Knowledge Systems Laboratory. Standford, California, p.9-45. 1991
[GRUENSTEIN, A.; MCGRAW, I.; BADR, I., 2008] GRUENSTEIN, A.; MCGRAW, I.;
BADR, I. The WAMI toolkit for developing, deploying, and evaluating web-accessible
multimodal interfaces. Proceedings of the 10th international conference on Multimodal
interfaces. Chania, Crete, Greece: ACM: 141-148 p. 2008.
[HAMEL, J.; DUFOUR, S.; FORTIN, D., 1993] HAMEL, J.; DUFOUR, S.; FORTIN, D.
Case Study Methods. Sage Publications, Inc, 1993. ISBN 0803954166. Disponvel em: <
http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-
20&path=ASIN/0803954166 >.
[HARTLEY, J., 1994] HARTLEY, J. Case Studies in Organizational Research. In:
CATHERINE CASSELL e GILLIAN SYMON (Ed.). Qualitative Methods in
Organizational Research: A Practical Guide: Sage Publications Ltd, 1994. p.208-229.
[HOLZINGER, A., 2005] HOLZINGER, A. Usability engineering methods for software
developers. Commun. ACM, v. 48, n. 1, p. 71-74, 2005. ISSN 0001-0782.
[HONKALA, M.; POHJA, M., 2006] HONKALA, M.; POHJA, M. Multimodal interaction
with xforms. Proceedings of the 6th international conference on Web engineering. Palo Alto,
California, USA: ACM: 201-208 p. 2006.
[HUBERT, R., 2006] HUBERT, R. Accessibility and usability guidelines for mobile devices
in home health monitoring. SIGACCESS Access. Comput., n. 84, p. 26-29, 2006. ISSN
1558-2337.
[JDOM, 2009] JDOM. JDOM 1.0. 2009. Disponvel em: < http://www.jdom.org/ >. Acesso
em: November.
[JINTAE, L., 1997] JINTAE, L. Design Rationale Systems: Understanding the Issues. 12:
78-85 p. 1997.
[JOHN W. STAMEY, J.; HONEYCUTT, T. L., 2004] JOHN W. STAMEY, J.;
HONEYCUTT, T. L. Christopher Alexander's fifteen properties applied to the design of
communication. Proceedings of the 22nd annual international conference on Design of
communication: The engineering of quality documentation. Memphis, Tennessee, USA:
ACM: 64-71 p. 2004.
Referncias
166
[JOHNSTON, M., 2009] JOHNSTON, M. Building multimodal applications with EMMA.
Proceedings of the 2009 international conference on Multimodal interfaces. Cambridge,
Massachusetts, USA: ACM: 47-54 p. 2009.
[JURAFSKY, D.; MARTIN, J. H., 2000] JURAFSKY, D.; MARTIN, J. H. Speech and
Language Processing: An Introduction to Natural Language Processing, Computational
Linguistics, and Speech Recognition. Prentice Hall PTR, 2000. 934 ISBN 0130950696.
[KAMEL, N.; AIT AMEUR, Y., 2007] KAMEL, N.; AIT AMEUR, Y. A Formal Model for
CARE Usability Properties Verification in Multimodal HCI. Pervasive Services, IEEE
International Conference on, 2007. p.341-348.
[KJELDSKOV, J.; GRAHAM, C., 2003] KJELDSKOV, J.; GRAHAM, C. A Review of
Mobile HCI Research Methods. 5th International Symposium on Mobile Human-Computer
Interaction Udine, Italy 1: 75-84 p. 2003.
[KLEMMER, S. R.; et al., 2000] KLEMMER, S. R.; SINHA, A. K.; CHEN, J.; LANDAY, J.
A.; ABOOBAKER, N.; WANG, A. Suede: a Wizard of Oz prototyping tool for speech
user interfaces. Proceedings of the 13th annual ACM symposium on User interface software
and technology. San Diego, California, United States: ACM: 1-10 p. 2000.
[KRUEGER, R.; CASEY, M., 2000] KRUEGER, R.; CASEY, M. Focus Groups: A
Practical Guide for Applied Research. Sage Publications, Inc, 2000. ISBN 0761920714.
Disponvel em: < http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-
20&path=ASIN/0761920714 >.
[KUNZ, W.; RITTEL, H. W. J., 1970] KUNZ, W.; RITTEL, H. W. J. Issues as Elements of
Information Systems. Working Paper No. 131, Berkeley, 1970.
[LAI, J.; et al., 2002] LAI, J.; DAHLB, N.;CK; J, A. Robustness in speech based
interfaces: sharing the tricks of the trade. CHI '02 extended abstracts on Human factors in
computing systems. Minneapolis, Minnesota, USA: ACM: 915-915 p. 2002.
[LARA, S. M. A. D.; et al., 2010] LARA, S. M. A. D.; WATANABE, W. M.; SANTOS, E.
P. B. D.; FORTES, R. P. M. Improving WCAG for elderly web accessibility. Proceedings
of the 28th ACM International Conference on Design of Communication. So Carlos, So
Paulo, Brazil: ACM: 175-182 p. 2010.
[LARSON, J. A., 2003] LARSON, J. A. W3C Multimodal Interaction Framework. W3C
Note 2003.
[LEWIS, C.; et al., 1990] LEWIS, C.; POLSON, P. G.; WHARTON, C.; RIEMAN, J.
Testing a walkthrough methodology for theory-based design of walk-up-and-use
interfaces. Proceedings of the SIGCHI conference on Human factors in computing systems:
Empowering people. Seattle, Washington, United States: ACM: 235-242 p. 1990.
[LIMBOURG, Q.; et al., 2005] LIMBOURG, Q.; VANDERDONCKT, J.; MICHOTTE, B.;
BOUILLON, L.; LPEZ-JAQUERO, V. USIXML: A Language Supporting Multi-path
Development of User Interfaces. In: RMI BASTIDE;PHILIPPE PALANQUE, e col (Ed.).
Referncias
167
Engineering Human Computer Interaction and Interactive Systems: Springer Berlin /
Heidelberg, v.3425, 2005. p.200-220. (Lecture Notes in Computer Science).
[LOPEZ-CEZAR, R.; et al., 2003] LOPEZ-CEZAR, R.; TORRE, A. D. L.; SEGURA, J. C.;
RUBIO, A. J. Assessment of dialogue systems by means of a new simulation technique.
Speech Commun., v. 40, n. 3, p. 387-407, 2003. ISSN 0167-6393.
[LUCREDIO, D.; et al., 2008] LUCREDIO, D.; BRITO, K. D. S.; ALVARO, A.; GARCIA,
V. C.; ALMEIDA, E. S. D.; FORTES, R. P. D. M.; MEIRA, S. L. Software reuse: The
Brazilian industry scenario. J. Syst. Softw., v. 81, n. 6, p. 996-1013, 2008. ISSN 0164-1212.
[MAES, S. H.; SARASWAT, V., 2003] MAES, S. H.; SARASWAT, V. Multimodal
Interaction Requirements 2003.
[MARCUS, A., 2002] MARCUS, A. Dare we define user-interface design? interactions, v.
9, n. 5, p. 19-24, 2002. ISSN 1072-5520.
[MCGEE, D. R.; COHEN, P. R.; OVIATT, S., 1998] MCGEE, D. R.; COHEN, P. R.;
OVIATT, S. Confirmation in multimodal systems. Proceedings of the 36th Annual
Meeting of the Association for Computational Linguistics and 17th International Conference
on Computational Linguistics - Volume 2. Montreal, Quebec, Canada: Association for
Computational Linguistics: 823-829 p. 1998.
[MCGLASHAN, S., 1999] MCGLASHAN, S. Dialog Requirements for Voice Markup
Languages. W3C Working Draft 1999.
[MCTEAR, M. F., 2002] MCTEAR, M. F. Spoken dialogue technology: enabling the
conversational user interface. ACM Comput. Surv., v. 34, n. 1, p. 90-169, 2002. ISSN
0360-0300.
[MELO, A. M.; et al., 2006] MELO, A. M.; CECILIA, M. BARANAUSKAS, L. C. Design
para a incluso: desafios e proposta. Proceedings of VII Brazilian symposium on Human
factors in computing systems. Natal, RN, Brazil: ACM: 11-20 p. 2006.
[MOLLER, S.; et al., 2009] MOLLER, S.; ENGELBRECHT, K. P.; KUHNEL, C.;
WECHSUNG, I.; WEISS, B. A taxonomy of quality of service and Quality of Experience of
multimodal human-machine interaction. Quality of Multimedia Experience, 2009. QoMEx
2009. International Workshop on, 2009. p.7-12.
[MONK, S.; et al., 1995] MONK, S.; SOMMERVILLE, I.; PENDARIES, J.; DURIN, B.
Supporting design rationale for system evolution. In: WILHELM SCHFER e PERE
BOTELLA (Ed.). Software Engineering ESEC '95: Springer Berlin / Heidelberg, v.989,
1995. p.307-323. (Lecture Notes in Computer Science).
[MORAN, T. P.; CARROLL, J. M., 1996] MORAN, T. P.; CARROLL, J. M. Design
Rationale: Concepts, Techniques, and Use New Jersey: Lawrence Erlbaum Associates, ,
1996.
Referncias
168
[MORI, G.; PATERNO, F.; SANTORO, C., 2004] MORI, G.; PATERNO, F.; SANTORO,
C. Design and Development of Multidevice User Interfaces through Multiple Logical
Descriptions. IEEE Trans. Softw. Eng., v. 30, n. 8, p. 507-520, 2004. ISSN 0098-5589.
[MURAKAMI, V. T., 2009] MURAKAMI, V. T. Princpios de usabilidade na Web com
interaes multimodais. Trabalho de Concluso de Curso. Sao Carlos: Maio de 2009, p.1-
121. 2009
[NARAYAN, M.; et al., 2004] NARAYAN, M.; WILLIAMS, C.; PERUGINI, S.;
RAMAKRISHNAN, N. Staging transformations for multimodal web interaction
management. Proceedings of the 13th international conference on World Wide Web. New
York, NY, USA: ACM: 212-223 p. 2004.
[NETO, A. T.; et al., 2006] NETO, A. T.; ANACLETO, J. C.; VANIA; NERIS, N. A.;
GODOI, M. D. S.; CARVALHO, A. F. P. A framework to support the design of learning
objects based on the Cog-Learn Pattern Language. Proceedings of the 12th Brazilian
Symposium on Multimedia and the web. Natal, Rio Grande do Norte, Brazil: ACM: 128-137
p. 2006.
[NETO, A. T.; FORTES, R. P. D. M., 2010] NETO, A. T.; FORTES, R. P. D. M. Improving
multimodal interaction design with the MMWA authoring environment. Proceedings of
the 28th ACM International Conference on Design of Communication. So Carlos, So
Paulo, Brazil: ACM: 151-158 p. 2010.
[NETO, A. T.; et al., 2009] NETO, A. T.; FORTES, R. P. D. M.; ASSIS, A. R.;
ANACLETO, J. C. Design of communication in multimodal web interfaces. Proceedings
of the 27th ACM international conference on Design of communication. Bloomington,
Indiana, USA: ACM: 81-88 p. 2009.
[NETO, A. T.; FORTES, R. P. M., 2009] NETO, A. T.; FORTES, R. P. M. Developing and
evaluating web multimodal interfaces - a case study with usability principles.
Proceedings of the 2009 ACM symposium on Applied Computing. Honolulu, Hawaii: ACM:
116-120 p. 2009.
[NICHOLS, J.; et al., 2002] NICHOLS, J.; MYERS, B.; HARRIS, T. K.; ROSENFELD, R.;
SHRIVER, S.; HIGGINS, M.; HUGHES, J. Requirements for Automatically Generating
Multi-Modal Interfaces for Complex Appliances. Proceedings of the 4th IEEE
International Conference on Multimodal Interfaces: IEEE Computer Society: 377 p. 2002.
[NIELSEN, J., 1993] NIELSEN, J. Usability Engineering. Morgan Kaufmann Publishers
Inc., 1993. 358 ISBN 0125184050.
[NIELSEN, J., 1995] NIELSEN, J. Usability inspection methods. Conference companion on
Human factors in computing systems. Denver, Colorado, United States: ACM: 377-378 p.
1995.
[NIELSEN, J., 1997] NIELSEN, J. The Use and Misuse of Focus Groups. IEEE Softw., v.
14, n. 1, p. 94-95, 1997. ISSN 0740-7459.
Referncias
169
[NIELSEN, J., 2004] NIELSEN, J. Risks of Quantitative Studies. Alertbox publicado em
Useit.com. http://www.useit.com/alertbox/20040301.html, 2004.
[NIELSEN, J., 2006] NIELSEN, J. Ensuring Web Usability: Understanding What Users
Want. New Riders Publishing, 2006. ISBN 0321286707.
[NIELSEN, J.; MOLICH, R., 1990] NIELSEN, J.; MOLICH, R. Heuristic evaluation of
user interfaces. Proceedings of the SIGCHI conference on Human factors in computing
systems: Empowering people. Seattle, Washington, United States: ACM: 249-256 p. 1990.
[NIELSEN, J.; TAHIR, M., 2001] NIELSEN, J.; TAHIR, M. Homepage Usability: 50
Websites Deconstructed. New Riders Publishing, 2001. 336 ISBN 073571102X.
[NORMAN, D. A., 1995] NORMAN, D. A. The psychopathology of everyday things. In:
(Ed.). Human-computer interaction: toward the year 2000: Morgan Kaufmann Publishers
Inc., 1995. p.5-21. ISBN 1-55860-246-1.
[OVIATT, S., 1997] OVIATT, S. Multimodal interactive maps: designing for human
performance. Hum.-Comput. Interact., v. 12, n. 1, p. 93-129, 1997. ISSN 0737-0024.
[OVIATT, S., 1999a] OVIATT, S. Mutual disambiguation of recognition errors in a
multimodel architecture. Proceedings of the SIGCHI conference on Human factors in
computing systems: the CHI is the limit. Pittsburgh, Pennsylvania, United States: ACM: 576-
583 p. 1999a.
[OVIATT, S., 1999b] OVIATT, S. Ten myths of multimodal interaction. Commun. ACM, v.
42, n. 11, p. 74-81, 1999b. ISSN 0001-0782.
[OVIATT, S., 2003] OVIATT, S. Multimodal interfaces. In: (Ed.). The human-computer
interaction handbook: fundamentals, evolving technologies and emerging applications:
L. Erlbaum Associates Inc., 2003. p.286-304. ISBN 0-8058-3838-4.
[OVIATT, S., 2003] OVIATT, S. User-centered modeling and evaluation of multimodal
interfaces. Proceedings of the IEEE, v. 91, n. 9, p. 1457-1468, 2003. ISSN 0018-9219.
[OVIATT, S.; et al., 2000] OVIATT, S.; COHEN, P.; WU, L.; VERGO, J.; DUNCAN, L.;
SUHM, B.; BERS, J.; HOLZMAN, T.; WINOGRAD, T.; LANDAY, J.; LARSON, J.;
FERRO, D. Designing the user interface for multimodal speech and pen-based gesture
applications: state-of-the-art systems and future research directions. Hum.-Comput.
Interact., v. 15, n. 4, p. 263-322, 2000. ISSN 0737-0024.
[OVIATT, S.; COULSTON, R.; LUNSFORD, R., 2004] OVIATT, S.; COULSTON, R.;
LUNSFORD, R. When do we interact multimodally?: cognitive load and multimodal
communication patterns. Proceedings of the 6th international conference on Multimodal
interfaces. State College, PA, USA: ACM: 129-136 p. 2004.
[OVIATT, S.; DEANGELI, A.; KUHN, K., 1997] OVIATT, S.; DEANGELI, A.; KUHN, K.
Integration and synchronization of input modes during multimodal human-computer
interaction. Proceedings of the SIGCHI conference on Human factors in computing systems.
Atlanta, Georgia, United States: ACM: 415-422 p. 1997.
Referncias
170
[OVIATT, S.; LUNSFORD, R.; COULSTON, R., 2005] OVIATT, S.; LUNSFORD, R.;
COULSTON, R. Individual differences in multimodal integration patterns: what are
they and why do they exist? Proceedings of the SIGCHI conference on Human factors in
computing systems. Portland, Oregon, USA: ACM: 241-249 p. 2005.
[OVIATT, S.; VANGENT, R., 1996] OVIATT, S.; VANGENT, R. Error resolution during
multimodal human-computer interaction. Spoken Language, 1996. ICSLP 96. Proceedings.,
Fourth International Conference on, 1996. p.204-207 vol.1.
[PATERNO, F., 1999] PATERNO, F. Model-Based Design and Evaluation of Interactive
Applications. Springer-Verlag, 1999. 192 ISBN 1852331550.
[PATERN, F., 2005] PATERN, F. Model-based tools for pervasive usability. Interacting
with Computers, v. 17, n. 3, p. 291-315, 2005. ISSN 0953-5438. Disponvel em: <
http://www.sciencedirect.com/science/article/B6V0D-4DB5FGK-
2/2/e0faa90a4e6b3b2be9f81b2c9bfd2014 >.
[PATERNO, F.; GIAMMARINO, F., 2006] PATERNO, F.; GIAMMARINO, F. Authoring
interfaces with combined use of graphics and voice for both stationary and mobile
devices. Proceedings of the working conference on Advanced visual interfaces. Venezia,
Italy: ACM: 329-335 p. 2006.
[PATERN, F.; SANTOS, I., 2007] PATERN, F.; SANTOS, I. Designing and Developing
Multi-User, Multi-Device Web Interfaces. In: GALLE CALVARY;COSTIN PRIBEANU, e
col (Ed.). Computer-Aided Design of User Interfaces V: Springer Netherlands, 2007.
p.111-122. ISBN 978-1-4020-5820-2.
[PREECE, J., 1993] PREECE, J., Ed. A Guide to Usability: Human Factors in
Computing. : Addison Wesley;, p.144 ed. 1993.
[PUERTA, A.; EISENSTEIN, J., 2002] PUERTA, A.; EISENSTEIN, J. XIML: a common
representation for interaction data. Proceedings of the 7th international conference on
Intelligent user interfaces. San Francisco, California, USA: ACM: 214-215 p. 2002.
[RAJANEN, M.; IIVARI, N., 2007] RAJANEN, M.; IIVARI, N. Usability cost-benefit
analysis: how usability became a curse word? Proceedings of the 11th IFIP TC 13
international conference on Human-computer interaction - Volume Part II. Rio de Janeiro,
Brazil: Springer-Verlag: 511-524 p. 2007.
[RAMAN, T. V., 2003] RAMAN, T. V. Design principles for multimodal interaction.
Computer Human Interfaces. Fort Lauderdale, USA.: 510 p. 2003.
[RATZKA, A., 2008] RATZKA, A. Explorative studies on multimodal interaction in a
PDA- and desktop-based scenario. Proceedings of the 10th international conference on
Multimodal interfaces. Chania, Crete, Greece: ACM: 121-128 p. 2008.
[RATZKA, A.; WOLFF, C., 2006] RATZKA, A.; WOLFF, C. A Pattern-Based Methodology
for Multimodal Interaction Design. In: PETR SOJKA;IVAN KOPECEK, e col (Ed.). Text,
Referncias
171
Speech and Dialogue: Springer Berlin / Heidelberg, v.4188, 2006. p.677-686. (Lecture
Notes in Computer Science).
[REEVES, L. M.; et al., 2004] REEVES, L. M.; LAI, J.; LARSON, J. A.; OVIATT, S.;
BALAJI, T. S.; ST; BUISINE, P.; COLLINGS, P.; COHEN, P.; KRAAL, B.; MARTIN, J.-
C.; MCTEAR, M.; RAMAN, T.; STANNEY, K. M.; SU, H.; WANG, Q. Y. Guidelines for
multimodal user interface design. Commun. ACM, v. 47, n. 1, p. 57-59, 2004. ISSN 0001-
0782.
[REGLI, W. C.; et al., 2000] REGLI, W. C.; HU, X.; ATWOOD, M.; SUN, W. A Survey of
Design Rationale Systems: Approaches, Representation, Capture and Retrieval. Engineering
with Computers, v. 16, n. 3, p. 209-235, 2000. ISSN 0177-0667. Disponvel em: <
http://dx.doi.org/10.1007/PL00013715 >.
[ROMBACH, D., 2000] ROMBACH, D. Fraunhofer: the German model for applied research
and technology transfer. Software Engineering, 2000. Proceedings of the 2000 International
Conference on, 2000. 2000. p.531-537.
[ROUSSEAU, C.; BELLIK, Y.; VERNIER, F., 2005] ROUSSEAU, C.; BELLIK, Y.;
VERNIER, F. Multimodal output specification / simulation platform. Proceedings of the
7th international conference on Multimodal interfaces. Torento, Italy: ACM: 84-91 p. 2005.
[SCHAPIRA, E.; SHARMA, R., 2001] SCHAPIRA, E.; SHARMA, R. Experimental
Evaluation of Vision and Speech based Multimodal Interfaces. Proc. Workshop on
Perceptive User Interfaces. Orlando, FL: ACM Digital Library p. 2001.
[SEFFAH, A.; et al., 2006] SEFFAH, A.; DONYAEE, M.; KLINE, R. B.; PADDA, H. K.
Usability measurement and metrics: A consolidated model. Software Quality Control, v. 14,
n. 2, p. 159-178, 2006. ISSN 0963-9314.
[SERRANO, M.; et al., 2008] SERRANO, M.; NIGAY, L.; LAWSON, J.-Y. L.; RAMSAY,
A.; MURRAY-SMITH, R.; DENEF, S. The openinterface framework: a tool for
multimodal interaction. CHI '08 extended abstracts on Human factors in computing
systems. Florence, Italy: ACM: 3501-3506 p. 2008.
[SHNEIDERMAN, B., 1998] SHNEIDERMAN, B. Designing the user interface: strategies
for effective human-computer interaction. Addison-Wesley Longman Publishing Co.,
Inc., 1998. 448 ISBN 0-201-16505-8.
[SOUVIGNIER, B.; et al., 2000] SOUVIGNIER, B.; KELLNER, A.; RUEBER, B.;
SCHRAMM, H.; SEIDE, F. The thoughtful elephant: strategies for spoken dialog systems.
Speech and Audio Processing, IEEE Transactions on, v. 8, n. 1, p. 51-62, 2000. ISSN
1063-6676.
[STANCIULESCU, A.; et al., 2005] STANCIULESCU, A.; LIMBOURG, Q.;
VANDERDONCKT, J.; MICHOTTE, B.; MONTERO, F. A transformational approach
for multimodal web user interfaces based on UsiXML. Proceedings of the 7th
international conference on Multimodal interfaces. Torento, Italy: ACM: 259-266 p. 2005.
Referncias
172
[SUHM, B., 1997] SUHM, B. Empirical evaluation of interactive multimodal error
correction. Automatic Speech Recognition and Understanding, 1997. Proceedings., 1997
IEEE Workshop on, 1997. p.583-590.
[SWADE, J.; REUSCH, P. J. A., 2007] SWADE, J.; REUSCH, P. J. A. XHTML+Voice vs.
SALT: Two Standards for Multimodal Websites. Intelligent Data Acquisition and Advanced
Computing Systems: Technology and Applications, 2007. IDAACS 2007. 4th IEEE
Workshop on, 2007. 6-8 Sept. 2007. p.555-558.
[TAIB, R.; RUIZ, N., 2007] TAIB, R.; RUIZ, N. Wizard of oz for multimodal interfaces
design: deployment considerations. Proceedings of the 12th international conference on
Human-computer interaction: interaction design and usability. Beijing, China: Springer-
Verlag: 232-241 p. 2007.
[TIDWELL, J., 2005] TIDWELL, J. Designing Interfaces
Patterns for Effective Interaction Design. new york: O'Reilly Media 2005. 352 ISBN 978-
0-596-00803-1
[TRAUM, D. R.; et al., 1996] TRAUM, D. R.; SCHUBERT, L. K.; POESIO, M.; MARTIN,
N. G.; LIGHT, M. N.; HWANG, C. H.; HEEMAN, P. A.; FERGUSON, G. M.; ALLEN, J. F.
Knowledge Representation in the TRAINS-93 Conversation System. University of
Rochester. 1996
[TRAUTH, E. M.; O'CONNOR, B., 2000] TRAUTH, E. M.; O'CONNOR, B. A study of the
interaction between information technology and society: an illustration of combined
qualitative research methods. 2000.
[VEER, G. V. D.; WELIE, M. V., 2000] VEER, G. V. D.; WELIE, M. V. Task based
groupware design: putting theory into practice. Proceedings of the 3rd conference on
Designing interactive systems: processes, practices, methods, and techniques. New York
City, New York, United States: ACM: 326-337 p. 2000.
[W3C, 1996] W3C. XML - Extensible Markup Language 1996.
[W3C, 2007] W3C. Voice Extensible Markup Language (VoiceXML) 2.1. W3C
Recommendation 2007.
[WAZLAWICK, R., 2009] WAZLAWICK, R. Metodologia de Pesquisa para Cincia da
Computao. Elsevier, 2009. 184 ISBN 8535235221.
[WEINSCHENK, S.; BARKER, D. T., 2000] WEINSCHENK, S.; BARKER, D. T.
Designing effective speech interfaces. John Wiley & Sons, Inc., 2000. 405 ISBN 0-471-
37545-4.
[WELIE, M., TRTTEBERG, H., 2000] WELIE, M., TRTTEBERG, H. Interaction
Patterns in User Interfaces. Pattern Languages of Programs (PLoP 2000). Monticello,
Illinois, USA 2000.
[WELIE, M. V., 2010] WELIE, M. V. Patterns in Interaction Design. 2010. Disponvel em:
< http://www.welie.com/ >. Acesso em: Novembro de 2010.
Referncias
173
[WELIE, M. V.; VAN DER VEER, G. C.; ELINS, A., 1999] WELIE, M. V.; VAN DER
VEER, G. C.; ELINS, A. Breaking down Usability. Interact 99. Edinburgh, Scotland. 1:
613-620 p. 1999.
[WIKIRPCINTERFACE, 2010] WIKIRPCINTERFACE. Wiki RPC Interface 2.8.4 2010.
Disponvel em: < http://www.jspwiki.org/wiki/WikiRPCInterface >. Acesso em: Novembro
de 2010.
Apndice A
175
Apndice A. Padres de projeto
multimodal referenciados nesta Tese
Design Pattern: Modality synchronization
Context: The voice interaction can be regarded as temporal, as the graphical interaction can be considered
spacial. When combined in a multimodal interface, these interaction modalities need to be synchronized to avoid
compromising the system usability.
Problem(basedonDR issues): Interfaces that are not syncronized can make the user confused and decrease the
overall usability.
DR Issue (From MMWA Task Model: Prompt ): how to stop TTS when the user select an option?
DR Issue (From MMWA Task Model: Actions): I want to play the next task prompt when the user press Tab to
move to the next task or when the user set the focus in the next task. How?
DR Issue (From MMWA Task Model: Actions): How to update the graphical interface when the user say an
option?
DR Issue (From MMWA Task Model: Actions): Once an option is selected I wanna go to the next task.
Forces(basedonDR Arguments):
Event-level synchronization: Inputs in one modality are captured at the level the individual DOM events and
immediately reflected in the other modality; when it makes sense
Field-level synchronization: Inputs in one modality are reflected in the other after the user changes focus (e.g.
moves from input field to input field) or completes the interaction with a field (e.g. completes a select in a
menu)
Form-level synchronization: Inputs in one modality are reflected in the other only after a particular point in the
presentation is reached (e.g. after a certain number of fields have been completed in the form).
Session-level synchronization: Inputs in one modality are reflected in the other only after a switch from one
modality to another.
Solution(basedonDR Positions): an input in one modality is reflected in the output in another modality/device
as well as way that it may be combined across modalities.
Design the consistency of focus between the various modalities.The visual browser verbal browsers should
present the same information at the same time.
In a multifield form, the focus field of the visual browser should correspond to the field prompt currently
presented by the verbal browser.
Example(basedonDR Positions):
Apndice A
176
The MMWA-ae Actions functionality automatically syncronizes the modalities and tasks according to events
that might occur during the interaction in the following way:
MULTIMODAL INTERACTION: task_graph -> onFocus -> xv:sync -> task_voice (sync graphic and voice
elements of the same task when a 'focus' event occurs)
MULTIMODAL INTERACTION: task_graph -> onChange -> stopTTS -> task_voice (sync graphic and voice
elements of the same task when a 'change' event occurs)
GRAPH/MULTIMODAL INTERACTION: task_graph -> onChange -> gotoTask-> next task (when using
graphical interface, go to the next task once the user completed the task filling the appropriate graphic field)
MULTIMODAL INTERACTION: task_voice -> onRECOGNITION -> xv:sync -> task_graph (sync graphic
and voice elements of the same task when a 'recognition' event occurs)
VOICE/MULTIMODAL INTERACTION: task_voice -> onRECOGNITION-> gotoTask-> next task (when
using VUI, go to the next task once the recognition event occurs)
Task 1 GUI --------------------------------------Task 1 VUI -------------------------------------- TASK N
|---------------------------------------------------------------|-----------------------------------------------------|
Focus -------------------------------------------------- sync -------------------------------------------> TTS
| <---------------------------------------------------------- play -----------------------------------------------TTS
|---------------------------------------------------------------|-----------------------------------------------------|
| <----------------------------------------------------------sync---------- RECO -------- goto-----------> Focus
|---------------------------------------------------------------|-----------------------------------------------------|
Change -------------------------------------------------- stop ---------------------------------------------> TTS
Change -------------------------------------------------- sync -----------------------------------------------> |
Change -------------------------------------------------- goto -----------------------------------------------> |
ResultingContext: Fusion and Fission
Apndice A
177
Design Pattern: Large Group Selection
Context: The interface shows, utters and allows the user to select a value which is part of a large set
of possible values.
Problem(based on DR issues): How should the interface show a large group of multimodal input
information to the user?
DR Issue (From MMHE (Heuristic Evaluation)): Users are not able to say an option in a combo box
because they cannot see the possible values. The only option is to expand the combo box.
DR Issue (From MMWA Task Model: Options): User needs to scroll down to see all the possible
values of a List.
DR Issue (From MMWA Task Model: Prompt): Prompt is taking too long. It contains more than 7
itens.
DR Issue (From MMLOG (User Testing), updated in the task model): : There are too many
nomatches and noinputs in the usabilityevaluation log file.
DR Issue (MMWA Task Model: Actions):: What should I do to sync the options between two or more
groups of information?
Forces(basedonDR Arguments):
The user should know what choices are available.
The user should be able to find the value they want quickly.
Small chunks of information make the choice easier and faster.
Large numbers of things take a long time to read/hear, take up lots of space and are complicate to
remember.
Experienced users like to respond without listening to the enumerated options, while novice users
will listen to the enumerated options before selecting an option.
Solution(basedonDR Positions):
Organize the set of possible values in two or more tasks and sync these tasks. Clearly show the
selected value up front and provide a default value (most used). Speak the options values in a
Consistent command format. Organize the dialog in the way most appropriate to how the user will be
searching. Allow experienced users to directly selecting the choice.
Consistent command format: Keyword recognition is much faster and accurate. Many tasks lend
themselves to keyword commands better than natural language sentences.
Example(basedonDR Positions):
Apndice A
178
Selecting a car from a list of Car types using HTML select, X+V Assign and DOM Events:
Given a blank select element:
<select size="2" name="Select_Model">
<option value="0"> </option>
<option value="1"> </option>
</select>
The VXML assign element is used to inform via JavaScript which vehicles to show, based on a
previous car type choice.
<if cond="carType == 'Van'"/>
<vxml:assign name="document.frm1.listcars.options[0]" expr="new Option('Pontiac Vibe','Pontiac
Vibe')"/>
<vxml:assign name="document.frm1.listcars.options[1]" expr="new Option('Blazer','Blazer')"/>
The JavaScript new Option('Pontiac','Pontiac') will create the first option. One can use this code to
build dynamic lists. This way one can break the large list into to tasks: SelectCarType and then
SelectRentCar.
Scrolled combo boxes are really only necessary if the dropdown list is going to run off the edge of the
screen -- it's easy to miss the choices beyond the visible area. It takes the bad features of scrolled lists
and makes them worse, first by making you show the list and then by shrinking the scrollbar.
Resulting Context: SkipChoice may let the user skip a task that does not need a mandatory input,
without even bothering to set the value. If the choices are tricky, or are cryptic in some other way,
ShortDescription may be needed to describe the choices further.
Apndice B
179
Apndice B. Relacionamentos entre
heursticas, checklists, guidelines e
princpios
A seguir apresentado um trecho do formulrio de avaliao heurstica, utilizado no estudi de
caso 1, que relaciona heursticas e checklists.
Heurstica
Checklist
1) Visibilidade do
estado sistema.
1.1 As modalidades de voz e visual esto sincronizadas para todos os componentes de interface e
para todas as possveis entradas da(s) gramtica(s) na interface multimodal?
1.2 O usurio consegue perceber a mudana de dilogo para cada interface multimodal?
1.3 O usurio consegue perceber a mudana de dilogo entre todos os componentes de interface?
1.4 possvel identificar transio entre os campos por uso de animao, som ou at mesmo
pausa?
1.5 A mudana de dilogo entre os componentes de interface realizada em um tempo aceitvel?
1.6 O tempo de espera para que o help seja lido par ao usurio est dentro de um tempo
aceitvel?
1.7 A confiabilidade de resposta do usurio reconhecida dentro de um tempo aceitvel?
1.8 Os componentes de interface, as gramticas e JavaScripts so atualizados durante a transio
de um dilogo para outro ou durante a transio de interfaces?
1.9 O usurio percebe o estado atual de uma tarefa e sabe quando a terminou?
2) Correspondncia
entre o sistema e o
mundo real
2.1 As listas de opes so lidas numa ordem lgica?
2.2 O help do sistema faz uso de conceitos e linguagem familiares aos usurios ao invs de
termos tcnicos?
2.3 Campos de senha ou de entrada de dados particulares permitem entrada por teclado ao invs
de voz? O resultado da entrada na interface no caso de senhas mascarado?
3) Controle e
liberdade do usurio
3.1 possvel ao usurio selecionar se deseja ou no que sejam lidas as listas de opes da caixa
de seleo?
3.2 O usurio pode fazer o que quer quando deseja? Ou seja, possvel cancelar a execuo do
sistema em qualquer momento ou solicitar por help?
Apndice B
180
4) Consistncia e
padronizao
4.1 Existem informaes duplicadas (texto e voz individualmente e separadamente) sendo
apresentadas ao usurio?
4.2 A terminologia e os comandos so consistentes entre as interfaces, componentes e
modalidades? Ou seja, os elementos visuais e de voz tem o mesmo significado?
5) Preveno de erros 5.1 O sistema multimodal faz com que usurios cometam erros que no cometeriam em sistemas
apenas com interface visual?
5.2 O sistema de Tratamento de Erros adaptado ao nmero de ocorrncias?
5.3 Existem informaes duplicadas (texto e voz individualmente e separadamente) sendo
5.4 O sistema consegue tratar erros de reconhecimento, estouro de tempo sem fala, ajudar o
usurio, repetir a ltima fala, voltar para um local seguro e conhecido pelo usurio?
5.5 Em virtude de mudana ou correo de sua solicitao, o usurio pode alterar suas
marcaes?
6) Ajuda aos usurios
para reconhecer,
diagnosticar e se
recuperar de erros
6.1 As mensagens de help so expressas em linguagem plena (sem cdigos)? Elas sugerem
uma soluo?
7) Reconhecimento ao
invs de memorizao
7.1 O sistema garante que a troca entre interfaces mantm os componentes atualizados sem que o
usurio precise memoriz-los?
7.2 O usurio consegue perceber qual modalidade ele deve utilizar para cada componente de
interface e para cada interface?
7.3 Existe alguma representao visual para auxiliar o usurio na identificao do tipo de
interface disponvel?
7.4 O usurio percebe facilmente o mecanismo de help?
7.5 O usurio percebe facilmente o mecanismo de acionamento de links?
7.6 As listas de opes das caixas de seleo esto claras para o usurio?
8) Flexibilidade e
eficincia de uso
8.1 O usurio consegue trocar de modalidade (voz para visual, ou visual para voz) durante a
interao? A interface e/ou seus componentes so atualizados?
8.2 Existe algum modo indisponvel em um determinado momento da interao?
8.3 Existe alguma lgica na aplicao multimodal que permita a adaptao da interface?
8.4 O usurio pode habilitar/desabilitar modalidades? Ou seja, escolher se deseja interagir de
forma grfica, por voz, ou utilizando ambas?
9) Design esttico e
minimalista
9.1 Os dilogos contidos no help contm informaes irrelevantes ou raramente utilizadas?
10) Ajuda e 10.1 Uma ajuda apropriada fornecida pelo help? Essa informao fcil de ser solicitada e
Apndice B
181
documentao focada na tarefa do usurio?
A seguir apresenta-se um trecho do formulrio utilizado no estudo de caso 1 para verificar a
consistncia das interfaces multimodais projetadas com os Princpios, guidelines e checklists
identificados nesta pesquisa para o desenvolvimento de interfaces multimodais Web.
1) As mltiplas modalidades precisam estar sincronizadas. A interao por voz pode ser considerada
como temporal, enquanto a interao visual grfica pode ser considerada espacial. Quando
combinadas em uma interface multimodal, esses modos de interao precisam estar sincronizados
para no comprometer a usabilidade do sistema.
CheckList - As modalidades de voz e visual esto sincronizadas para todos os componentes de
interface e para todas as possveis entradas da(s) gramtica(s) na interface multimodal?
Guideline: Projete a consistncia no foco entre as diversas modalidades.
Aplicao: sim, foi feita a sincronia dos componentes de interface e para todas as possveis
entradas das gramticas na interface multimodal.
*componentes de interface - traduo de widget. So as partes que formam a interface Web como:
campos de texto, listas, itens de seleo, botes, links, etc; e no caso das interfaces de voz: prompts,
entradas e sadas de gramticas, formulrios, menus, etc.
2) A transio entre dilogos em uma interao multimodal deve ser perceptvel ao usurio, pois as
suas habilidades e necessidades, bem como o contexto de uso pode ser modificado durante a
interao.
CheckList - O usurio consegue perceber a mudana de dilogo para cada interface multimodal?
Aplicao: sim, isso feito com a verificao da mudana de foco, seja pelo reconhecimento de
alguma frase, seja pela interao coma interface grfica.
3) As mltiplas modalidades devem compartilhar o estado de interao para que durante a
mudana de uma interface para outra ou se o usurio desejar trocar de modalidade em uma
determinada seqncia do dilogo humano-computador, as vrias mdias disponveis sejam
atualizadas.
CheckList - Os componentes de interface, as gramticas e JavaScripts so atualizados durante a
transio de um dilogo para outro ou durante a transio de interfaces?
CheckList - O usurio consegue trocar de modalidade (voz para visual, ou visual para voz) durante a
interao? A interface e/ou seus componentes so atualizados?
Aplicao: sim, quando h uma transio entre modalidades as variveis que contemplam o
reconhecimento do valor de atribuio dos campos so tratadas novamente para compartilhar o
estado de interao. Inclusive, caso o usurio confirme via voz o submit do formulrio o boto
pressionado via voz ou pode faz-lo via teclado.
Apndice B
182
4) As interfaces multimodais devem ser previsveis, ou seja, a interface precisa possibilitar que o
usurio saiba intuitivamente qual o melhor modo para se utilizar durante a execuo de uma tarefa. A
interface deve permitir que o usurio perceba se em um dado momento algum modo estiver
indisponvel.
CheckList - O usurio consegue perceber qual modalidade ele deve utilizar para cada componente de
interface e para cada interface?
CheckList - Existe algum modo indisponvel em um determinado momento da interao? Descreva o
DR para cada caso separadamente e diga como o usurio alertado ou percebe essa situao.
Aplicao: sim, os DRs para tanto esto separados na Wiki pelas discusses. As interfaces esto
bem previsveis com a gramtica de modo flexvel com muitas expresses opcionais para que o
match ocorra de forma mais segura. Sobre a questo intuitiva foram usados componentes
grficos para reforar a corretude da interao como mostrar uma foto do carro e cidade
desejada no momento da escolha.
5)As interfaces multimodais devem se adaptar ao ambiente do usurio para assegurar que o melhor
modo de se completar uma determinada tarefa em um determinado momento estar disponvel ao
usurio. A adaptatividade tambm considerada como uma guideline. As interfaces multimodais
devem se adaptar s necessidades e habilidades de diferentes usurios e a diferentes contextos de uso.
A adaptatividade dinmica permite que a transio entre dilogos em uma interao seja perceptvel
ao usurio por meio de modalidades complementares.
CheckList - Existe alguma lgica na aplicao multimodal que permita a adaptao da interface? Em
que caso isto poderia se utilizado?
Aplicao: sim, um componente para isso a possibilidade de aumento e diminuio do
tamanho da fonte utilizada. Caso fosse usada uma linguagem dinmica acreditamos que essa
adaptabilidade seja bem maior, mas fica como um prximo estudo de melhoria de nosso
trabalho.
6) Durante a Especificao de Requisitos, o projeto da interao multimodal deve ser pensado para
uma grande gama de usurios e contextos de uso. Alm disso, o projetista deve considerar questes
de privacidade e de segurana.
CheckList - Que tipo de usurio consegue utilizar a interface (ou o componente) que est sendo
desenvolvida?
CheckList - (Privacidade) campos de senha ou de entrada de dados particulares devem permitir
entrada por teclado ao invs de voz e mascarar o resultado da entrada na interface no caso de senhas.
Aplicao: no caso da aplicao desenvolvida os usurios devem dominar a lngua inglesa para
a boa interao, principalmente na questo de voz. Sobre Privacidade no existe o campo de
senha ou outro que exija uma maior preocupao nesse sentido.
7) Projeto da entrada e sada multimodal. O projetista deve utilizar o recurso de mltiplas
modalidades para maximizar as habilidades humanas cognitivas e fsicas. Alm disso, deve evitar a
Apndice B
183
apresentao de informaes desnecessrias nas diferentes modalidades, com o objetivo de maximizar
as vantagens de cada modalidade para reduzir a carga de memria do usurio durante a execuo de
uma tarefa. importante tambm integrar as modalidades de maneira compatvel com as preferncias
do usurio, contexto e funcionalidades do sistema.
CheckList - Existem informaes duplicadas (texto e voz individualmente e separadamente) sendo
CheckList - Quais funcionalidades do sistema so melhor utilizadas usando-se interfaces ou
componentes de voz? e grfico? e ambos simultaneamente? Explique suas decises?
Guideline: Para cada tarefa, use o modo de interao mais simples disponvel no dispositivo.
Guideline: Se a mo ou a viso do usurio est ocupada, use interface de voz.
Guideline: se o usurio est em um ambiente ruidoso, use o toque ou interface grfica.
Guideline: Use udio para indicar que a informao fornecida deve ser verbal.
Guideline: Use pausas para dividir a informao em "grupos" naturais.
Guideline: Use animao e som para indicar transies.
Guideline: Use navegao por voz para reduzir o numero de telas
Guideline: Use interface grfica para facilitar a reteno de informao na memria de curta durao
do usurio.
exemplos:
* Se uma lista contem mais do que 72 itens, mostre as opes na tela.
se um texto contem mais do que duas sentenas, apresente-o visualmente ao usurio
Aplicao: Informaes duplicadas foram tratadas, tanto na interface grfica quanto na
interao por voz. A aplicao utiliza interface grfica e componentes de voz de maneira que os
componentes de voz auxiliam no preenchimento da interface. Os textos foram dispostos na tela
para que o usurio retenha informaes que podem ser usadas posteriormente para
preenchimento com voz
8) Consistncia na interao. As Interfaces visuais e de voz devem compartilhar ao mximo as
caractersticas comuns e devem se referenciar a uma tarefa com a mesma terminologia nas diferentes
modalidades.
CheckList - A terminologia e os comandos so consistentes entre as interfaces, componentes e
modalidades?
Guideline: Permita ao usurio falar palavras-chave ao invs de sentenas complexas. Coloque essas
palavras nos prompts do sistema.
Aplicao: sim, os comandos so consistentes e as palavras que o usurio deve utilizar como
respostas para o preenchimento da interface grfica so simples e visveis na interface.
Apndice B
184
9) Retorno (feedback) Os usurios devem perceber que modalidades esto presentes em determinado
momento da interao e devem perceber quais so os tipos de interao alternativas que esto
presentes para executar uma tarefa.
CheckList - o usurio percebe o estado atual de uma tarefa e sabe quando a terminou?
Guideline: use sada de voz para informar ou comentar uma ao do usurio ou fornecer informao
complementar.
Guideline: Apresente a(s) palavra(s) reconhecida(s) pelo ASR na forma visual, para que o usurio
possa verificar se o que foi reconhecido est correto.
Guideline: Mostre uma lista n-best para habilitar a correo de erros de reconhecimento de fala
Guideline: Tempo de resposta deve ser menor que 5seg. Informe ao usurio quando houver demora
em consultas de BD.
Guideline: Sempre mostre o status do sistema ao usurio. Indique o caminho percorrido na forma
grfica. e permita falas do tipo "Repita", "volte", "menu principal"
Aplicao: quando a aplicao inicia, executada uma mensagem de voz de maneira
evidenciando ao usurio a possibilidade de voz. As aes incorretas do usurio so comentadas.
H comentrios para ocorrncia de erros e possibilidade de voltar pelo caminho percorrido na
interface.
10) Tratamento e preveno de erros.
Os erros podem ser evitados e minimizados e o tratamento de erros pode ser melhorado quando a
interface fornece claramente ao usurio quais sadas o sistema disponibiliza e permitindo que ele
reverta ou recupere suas aes quando desejado. Os usurios novatos ocasionalmente podem no
responder a um prompt de maneira adequada. A interface deve ser projetada para detectar tais erros e
ajudar os usurios a se recuperarem naturalmente. As interfaces multimodais devem ajudar o usurio a
aprender como usar as mltiplas modalidades para atingir os resultados desejados rpida e
eficientemente.
CheckList - Existem informaes duplicadas (texto e voz individualmente e separadamente) sendo
CheckList - O sistema consegue tratar erros de reconhecimento, estouro de tempo sem fala, ajudar o
usurio, repetir a ultima fala, voltar para um local seguro e conhecido pelo usurio?
Guideline: Sempre fornea ajuda sensvel ao contexto para cada ao.
Princpio reflexivo. As pessoas tendem a responder de maneira parecida como so perguntadas.
Perguntas longas sero respondidas com respostas longas. Trechos da pergunta freqentemente so
usados na resposta.
Guideline: O usurio tende a usar o mesmo modo no qual foi feita a pergunta para fornecer a resposta.
Aplicao: feito verificaes de erros nos campos obrigatrios, tanto pelo modo grfico ou por
voz voltando o foco no campo que apresentar erro.
Apndice C
185
Apndice C. Exemplo de DR identificado
em um estudo de caso
Questo: A seleo por voz do campo "Type Car" deve filtrar a lista de carros exibidos no campo
"List of cars". Assim, se o usurio optar por tipo de carro igual a "Van", apenas carros dessa
categoria devem ser exibidos na lista. Como sincronizar esses dois eventos?
PosioDesenvolvedor 1: utilizar <select>
ArgumentoDesenvolvedor 1: Quando seleciono van, car ou motocycle eu gostaria que
apresentasse uma lista com os respectivos veiculos de cada categoria. Eu estou utilizando o
componente <select> s que eu no sei realizar um filtro e depois setar no select apenas os cars..
ou vans.. ou motocycles... Tentei fazer com <assign>, porem no consegui.
PosioDesenvolvedor 4: : o <assign> do vxml serviria para informar via JavaScript para o
select quais veiculos mostrar.
ArgumentoDesenvolvedor 4:
<vxml:assign name="document.frm1.listcars.options[0]" expr="new
Option('Pontiac','Pontiac')"/>
<vxml:assign name="document.frm1.listcars.options[1]" expr="new Option('Buick','Buick')"/>
a tag <assign> vxml mas o conteudo dela jscript.
Questo Desenvolvedor 1: esse comando ja cria uma option no select?
PosioDesenvolvedor 4: : no, vc tem que ter o form html pronto e o select com o nome
listcars. E este select no est em branco, entende? Ele j contm j de nicio no mnimo duas
opes referentes ao tipo 'Car'. E caso anteriormente o usurio tenha escolhido o tipo 'Both', esse
select est com quatro opes.
Questo Desenvolvedor 1: Ento esse select no incio est assim?
<select name="listcars" id="idlistcars" class="input-box2">
<option value="Pontiac">Pontiac</option>
<option value="Buick">Buick</option>
</select>
PosioDesenvolvedor 4: Certo.
Da os seguintes comandos removem as oes que estavam l anteriormente. Se tinha duas, todas
foram retiradas. Se tinham quatro, duas foram retiradas.
<vxml:assign name="document.frm1.listcars.options[1]" expr="null"/>
<vxml:assign name="document.frm1.listcars.options[0]" expr="null"/>
Dependendo do tipo do carro que ele escolheu ('Car','Van' ou 'Both'). Colocamos novas opes no
select. Para o caso do usurio ter escolhido 'Van', colocaramos as opes de
carros 'Pontiac Vibe' e 'Blazer' por meio dos comandos:
Apndice C
186
<vxml:assign name="document.frm1.listcars.options[0]" expr="new Option('Pontiac
Vibe','Pontiac Vibe')"/>
<vxml:assign name="document.frm1.listcars.options[1]" expr="new Option('Blazer','Blazer')"/>
s que o nome dele tem que ser listcars, por causa do JavaScript:
document.frm1.listcars.options[0] e o seu form HTML tem que chamar "frm1" nesse caso, o
atributo 'action' est vazio pois no estamos salvando a informao da reserva do carro em
nenhum banco de dados. J que isso no est no escopo do projeto atualmente. ou vc troca o
nome no JavaScript.
*Soluo adotada*: A sincronizao realizada utilizando o comando <assign>. Caso o usurio
escolha a opo de "Car" automaticamente selecionado no formulrio html as opes [0] e [1]:
'Pontiac', 'Buick'. Se a opo for por "Van", os itens [0] e [1] setados no formulrio so 'Pontiac
Vibe' e 'Blazer'. Caso a opo seja "Both", as 4 opes anteriores so exibidas nas opes [0], [1],
[2] e [3].
Apndice D
187
Apndice D. Questionrio aplicado a um
desenvolvedor que utilizou o MMWA-
ae
O questionrio a seguir, baseado no questionrio SUMI
14
, foi aplicado a um dos desenvolvedores que
utilizaram o MMWA-ae.
Concordo Neutro Discordo
Tanto a quantidade ou a qualidade das informaes de ajuda varia dentro do
sistema. X
Este software responde muito lentamente s entradas X
Eu recomendaria esse software aos meus colegas. X
As instrues e mensagens de solicitao so teis. X
O software travou inesperadamente. X
Aprender operar esse software inicialmente cheio de problemas. X
s vezes eu no sei qual a prxima ao a realizar na execuo de uma
dada tarefa com esse software. X
Eu gosto de projetar interfaces com esse software. X
Eu acho que a informao de ajuda dada por esse software no til. X
Se esse software trava, no fcil de reinici-lo. X
A aprendizagem dos comandos desse software muito lenta. X
s vezes tenho dvida se estou utilizando o comando correto. X
Projetar Interfaces com esse software prazeroso. X
O modo que a informao do sistema apresentada claro e entendvel. X
Eu me sinto mais seguro usando poucos comandos ou operaes familiares. X
A documentao do software bastante informativa. X
Este software parece que rompe o modo que eu normalmente gosto de
realizar o meu trabalho. X
Utilizar esse software mentalmente estimulante. X
Nunca h informao na tela quando necessrio. X
Eu me sinto no comando desse software quando estou usando o mesmo. X
Prefiro utilizar as funcionalidades que eu conheo melhor. X
Acho que esse software inconsistente. X
No gostaria de trabalhar com esse software todos os dias. X
Consigo entender e utilizar as informaes fornecidas por esse software. X
Este software ruim quando eu quero fazer algo que no seja simples. X
H muito o que aprender antes de conseguir usar o software. X
As tarefas podem ser realizadas de uma maneira bem direta usando esse
software. X
Usar esse software frustrante. X
O software me ajudou superar qualquer problema que eu tenha tido ao
utiliz-lo. X
14
http://sumi.ucc.ie/
Apndice D
188
A velocidade desse software rpida suficiente. X
Eu tenho que olhar as instrues para utilizar esse software. X
bvio que as necessidades dos usurios foram totalmente levadas em
considerao. X
Houve momentos durante a minha utilizao do software que eu me senti
tenso. X
A organizao dos menus ou das listas de informao parece ser bastante
lgica. X
O software permite que o usurio seja econmico em digitao ou cliques
de mouse. X
Aprender usar as funcionalidades difcil. X
H muitos passos que devem ser executados durante o trabalho X
Acho que esse software j me deixou confuso em certa ocasio. X
Mensagens de preveno de erro no so adequadas. X
fcil fazer o software realizar exatamente o que voc deseja. X
Nunca aprenderei todas as funcionalidades que esse software oferece. X
O software nem sempre fez o que eu esperava. X
O software possui uma apresentao atraente. X
Tanto a quantidade ou a qualidade das informaes de ajuda varia dentro do
sistema. X
relativamente fcil mover de uma parte da tarefa para a outra. X
fcil de esquecer de fazer algumas coisas. X
Este software ocasionalmente se comporta de um modo que eu no entendo. X
Esse software realmente muito difcil. X
fcil de descobrir as opes disponveis para cada estgio de execuo de
uma tarefa. X
Eu preciso procurar por assistncia a maioria das vezes que estou usando o
software. X
Apndice E
189
Apndice E. Trechos de artefatos
desenvolvidos no EC1
Artefato #1 - Interface Grfica
Tela Principal
Definio Interface Grfica = Prototipao
20/05
NAME CAR RENTAL LOGOTIPO
Welcome to online Car Rental
Welcome to car World, a multimodal web page where you can rent your cars!
Search a car
City
Withdrawal : Airport Store
Date:
Hour: :
Car type :
List of cars :
Optionals : GPS Navigation ($12.95 per day)
Child Safety Seats ($5.50 per day)
Rent type : Daily rate
Kilometers
Number of days:
Insurance: Yes No
!&"$#%
;SW 1RKIPIW #
(# 8ER[EV[ #
''# 1<# '(#
2EV #
5KNC
7RXIVQIHMEXI >SRXMEG 5- #
(
Apndice E
190
Artefato #2 - Interface Grfica
Detalhes dos Carros
Definio Interface Grfica = Prototipao
20/05
Names Vehicle
Car Capacity:
x People
x Doors
Others Optionals
" Optional 1
" Optional 2
" Optional 3
Apndice E
191
Artefato #3 : Interface + Voice + Sincronizao
Definio Interface Voz
Seqncia Iteraes
1- Computador
Mensagem Inicial
Welcome to car World, a multimodal web page
where you can rent your cars!
Cdigo Fonte: Uso do Recurso Block

2- Computador
Mensagem Sobre o Campo City
Please inform the name of the city where you
intend to rent your car.
Cdigo Fonte: Uso do Recurso Prompt e
Enumerate
<vxml:prompt>Msg
<enumerate/></vxml:prompt>
<vxml:option value="Los Angeles"> Los Angeles
</vxml:option> ... Demais opes
3- Usurio Sistema
Usurio fala o nome da cidade desejada
Possibilidades:
" Fala coincidir com a gramtica. Ir para
" Usurio solicitar HELP . Ir para
Tratamento de Erros (A)
" Usurio no falar nada. Ir para Tratamento
de Erros (B)
Tratamento de erros: Uso do Recurso Elemento Catch
A- Help
<vxml:catch event="help"> Please inform the name of the city where you intend to
rent your car.</vxml:catch>
B- NoI nput / Nomatch
<vxml:catch event="noinput nomatch"> A noinput or a notmach
occured.</vxml:catch>
Sincronizao Voice/Interface
<vxml:field name="city" xv:id="vcity">
$
%
Apndice E
192
<vxml:assign name="document.frm1.city.value" expr="city"/>
Seqncia Iteraes
1- Computador
Mensagem Sobre o Campo withdrawal
Do you prefer to withdrawal your car on?
Enumerate
<vxml:prompt>Msg
<vxml:option value="airport"> Aiport
</vxml:option>
<vxml:option value="store"> Store </vxml:option>
3- Usurio Sistema
Usurio fala o local
Possibilidades:
de Erros (B)
A- Help
<vxml:catch event="help">Please inform the local where do you prefer to withdrawal
your car.</vxml:catch>
<vxml:catch event="noinput nomatch">A noinput or a notmach occured.
</vxml:catch>
<vxml:field name="withdrawal" xv:id="vwithdrawal">
%
&
Apndice E
193
<vxml:if cond="withdrawal == 'airport'">
<vxml:assign name="document.getElementById('airport').checked" expr="true"/>
<vxml:else/>
<vxml:assign name="document.getElementById('store').checked" expr="true"/>
</vxml:if>
Seqncia Iteraes
1- Computador
Mensagem Sobre o Campo Car Type
What kind of car do you want?
Enumerate
<vxml:prompt>Msg
<vxml:option value = "Car" > Car </vxml:option>
Demais Opes
3- Usurio Sistema
Usurio fala o tipo do Carro
Possibilidades:
de Erros (B)
A- Help
<vxml:catch event="help"> Please inform the kind of the car. </vxml:catch>
<vxml:catch event="noinput nomatch"> A noinput or a notmach occured.
</vxml:catch>
<vxml:field name="typecar" xv:id="vtypecar">
&
'
Apndice E
194
<xv:sync xv:field="#vtypecar" xv:input="typecar" />
Seqncia Iteraes
1- Computador
Mensagem Sobre o Campo Optionals
What optionals would you like? There are the
following options: GPS Navigation and Child
Safety Seats.
3- Usurio Sistema
Usurio fala os opcionais
Possibilidades:
de Erros (A)
Deciso Projeto: Usurio pode escolher mais de um opcional.
A- Help- NoI nput / Nomatch
<vxml:catch event="help nomatch noinput">For example, say GPS Navigation and
Child Safety Seats.</vxml:catch>
<vxml:if cond="optionals.search(/none/i) != -1"><vxml:assign
name="document.getElementById('inputgps').checked" expr="false"/>
<vxml:assign name="document.getElementById('inputchild').checked"
expr="false"/>
<vxml:else/>
<vxml:if cond="optionals.search(/GPS Navigation/i) != -1">
<vxml:assign name="document.getElementById('inputgps').checked"
expr="true"/>
'
(
Apndice E
195
</vxml:if>
<vxml:if cond="optionals.search(/Child Safety Seats/i) != -1">
<vxml:assign name="document.getElementById('inputchild').checked"
expr="true"/>
</vxml:if>
</vxml:if>
Gramtica:
<vxml:grammar>
<![CDATA[
#JSGF V1.0;
grammar optionals_grammar;
<optionals> = GPS Navigation | Child Safety Seats | none;
public <toppings> = (<optionals> [and]) + ;
]]>
</vxml:grammar>
Seqncia Iteraes
1- Computador
Mensagem Sobre o Campo Rent Type
What rent type do you want?
Enumerate
<vxml:prompt>Msg
<vxml:option value = "dailyrate">Daily
rate</vxml:option>
<vxml: option value = "kilometers">
Kilometers</vxml:option>
3- Usurio Sistema
Usurio fala o tipo do Aluguel
Possibilidades:
(
)
Apndice E
196
de Erros (B)
A- Help
<vxml:catch event="help"> Please inform the rent type.</vxml:catch>
</vxml:catch>
<vxml:field name="renttype" xv:id="vrenttype">
<xv:sync xv:field="#vrenttype" xv:input="renttype" />
Seqncia Iteraes
1- Computador
Mensagem Sobre o Campo Number of days
Say the number of days that you are going to rent
the car.
3- Usurio Sistema
Usurio fala o Nmero de Dias
Possibilidades:
de Erros (B)
A- Help
)
*
Apndice E
197
<vxml:catch event="help"> Please inform the number of days that you are going to
rent the car. </vxml:catch>
</vxml:catch>
<vxml:field name="numberofdays" xv:id="vnumberofdays" type="digits">
<vxml:assign name = "document.getElementById ('numberofdays'). value"
expr="numberofdays"/>
Seqncia Iteraes
1- Computador
Mensagem Sobre o Campo Insurance
Do you want insurance?
3- Usurio Sistema
Usurio fala se optar por Seguro
Possibilidades:
de Erros (B)
A- Help
<vxml:catch event="help"> Please inform if you want insurance.</vxml:catch>
</vxml:catch>
<vxml:if cond="insurance">
<vxml:assign name="document.getElementById('yes').checked" expr="true"/>
*
+
Apndice E
198
<vxml:else/>
<vxml:assign name="document.getElementById('no').checked" expr="true"/>
</vxml:if>
Seqncia Iteraes
1- Computador
Mensagem Final de Confirmao
Computador repete todas as opes selecionadas
pelo usurio
Value Expr
<vxml:prompt> You said <vxml: value
expr="city"/>, <vxml:value expr="withdrawal"/>,
<vxml:value expr="typecar"/>, <vxml: value
expr="optionals" />, <vxml: value expr="renttype"
/>, <vxml: value expr="numberofdays"/> and
<vxml: value expr="insurance"/> to insurance. Is
this correct? </vxml:prompt>
3- Usurio Sistema
Usurio confirma ou no confirma
Possibilidades:
" Fala coincidir com a gramtica do tipo
BOOLEAN
o Confirmao do Usurio: Link
para Fechar.
o No Confirmao do Usurio:
Link para correo.
<vxml:field name="confirm" type="boolean">
+
Apndice E
199
Legenda:
Tipo Descrio
Voice (Computador)
Voice (Usurio)

Tese Americo Revisada

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tese Americo Revisada

Uploaded by

Copyright:

Available Formats

Uma abordagem para projeto de aplicaes com

interao multimodal na Web

e o console Kinect para Xbox da

, e com a criao de mecanismos para acesso e simulao de testes em dispositivos

You might also like