Um Método da Engenharia Semiótica para a

Construção de Sistemas de Ajuda Online

Milene Selbach Silveira1,2 Clarisse Sieckenius de Souza2 Simone D.J.Barbosa2
Milene@inf.pucrs.br clarisse@inf.puc-rio.br simone@inf.puc-rio.br
FACIN – PUCRS1
Av.Ipiranga, 6681 – Prédio 30
Porto Alegre, RS 90619-900 - Brasil
SERG - DI/PUC-Rio2
R. Marquês de São Vicente, 225
Rio de Janeiro, RJ 22453-900 – Brasil

ABSTRACT podem produzir atitudes mais positivas em relação à ajuda

Online help systems are typically used (if at all) as a last
resource in interactive breakdown situations. In this paper,
we present a semiotic engineering method for building
online help that uses fairly known design models. We
discuss the benefits of having designers explicitly
communicate their design vision to users and the need or
opportunity to foster new cultural attitudes towards online
help. We show how, as a direct communication channel
from designers to users, it opens new possibilities for
interaction that can be skillfully used by designers. By
exploring such possibilities, designers and users may bring
about more positive attitudes towards online help and
counter the feeling of technological exclusion which many
users express.
Keywords
Online help systems; semiotic engineering; HCI design;
design models; technology adoption
RESUMO
Sistemas de ajuda online são tipicamente usados (quando o
são) como um último recurso quando encontra-se um
problema durante a interação. Neste artigo, apresentamos
um método da Engenharia Semiótica para construção de
sistemas de ajuda online, método este que utiliza modelos
de design de IHC amplamente conhecidos. Discutimos os
benefícios de ter os designers comunicando –
explicitamente – sua visão de design aos usuários, e a
necessidade ou oportunidade de adotar-se novas atitudes
culturais em frente a sistemas de ajuda. Mostramos como –
sendo um canal direto de comunicação dos designers para
os usuários – o sistema de ajuda abre novas possibilidades
de interação a serem exploradas pelos designers. Pela
exploração de tais possibilidades, designers e usuários
online, indo em contra ao sentimento de exclusão
tecnológica que muitos usuários expressam.
Palavras Chave
Sistemas de ajuda online; engenharia semiótica; design de
IHC; modelos de design; adoção de tecnologia
INTRODUÇÃO
Como podemos ajudar os designers a construir o sistema de
ajuda online de uma aplicação? E como assegurar que este
sistema mostrará aos usuários o que eles podem fazer com
a aplicação, para que ela serve, por que certas decisões de
design foram tomadas e assim por diante?
Esta série de perguntas reflete uma perspectiva antagônica
àquela que se popularizou sob o rótulo de idiot-proof
technology. Nesta, acredita-se que a meta de design deve
ser, no caso de software, por exemplo, a construção de
aplicações intuitivas, a prova de erro, e que na medida do
possível façam automaticamente pelos usuários todas as
coisas necessárias mas difíceis de fazer manualmente.
Como Adler e Winograd [1], as autoras deste trabalham
acreditam que esta visão é depreciativa e subestima, se não
impede, o exercício da inteligência e da criatividade do
usuário, para aprender e transformar o software de acordo
com o que a sua necessidade ou imaginação indicam.
Assim, enquanto numa perspectiva idiot-proof o papel da
ajuda online é constrangedor (porque denuncia o que não é
intuitivo ou o que o usuário precisa de explicações para
conseguir fazer), na perspectiva exposta por Adler e
Winograd o papel da ajuda online é o de abrir
possibilidades e de dar recursos para o usuário
compreender e transcender a idéia original do design,
tirando o melhor partido possível da tecnologia.
A construção do sistema de ajuda online de uma aplicação
é um dos passos mais críticos no design de IHC (Interação
Humano-Computador). Tipicamente estes sistemas acabam
por não ajudar muito os usuários e algumas das razões para
esta falta de eficiência podem ser: a falta de tempo ou de
planejamento para realizar esta parte do projeto; a
excessiva confiança ou expectativa com relação à

167
intuitividade da interface construída; ou ainda uma ingênua
aceitação dos padrões correntes [19].
Este trabalho é baseado na Engenharia Semiótica [7], para
a qual a interface de uma aplicação é uma mensagem
enviada dos designers aos usuários, representando a
solução do designer para o que ele acredita que são os
problemas dos usuários. É através desta mensagem que os
designers falam aos usuários o que eles interpretaram ser as
necessidades e preferências destes usuários, qual foi sua
resposta para estas necessidades e como eles concretizaram
sua visão na forma de um sistema interativo.
Para a Engenharia Semiótica, o sistema de ajuda online é
um componente essencial da aplicação. É através dele que
os designers podem “falar” mais direta e elaboradamente
aos usuários, revelando como a aplicação foi construída,
como ela pode ser usada e para que fins.
Este artigo descreve um método para design de sistemas de
ajuda online concebido à luz da Engenharia Semiótica e
com base em dois pilares principais: a comunicabilidade e a
técnica retórica de layering da abordagem minimalista. E, a
fim de ilustrar o método proposto, é apresentado o design
do sistema de ajuda online de uma apresentação real. A
discussão sobre este método está fundamentalmente
relacionada à possibilidade, senão à necessidade, de uma
mudança da cultura vigente em relação a este importante
recurso de interação. Em particular, faz-se uma ligação
explícita entre a qualidade da ajuda online e os sentimentos
de exclusão tecnológica comumente notados junto aos
usuários.
SISTEMA DE AJUDA ONLINE DO PONTO DE VISTA DA
ENGENHARIA SEMIÓTICA
É essencial que os usuários entendam a mensagem dos
designers para que eles possam fazer um melhor uso e tirar
melhor proveito de todas funcionalidades da aplicação.
Uma forma de tornar esta mensagem explícita e mais rica é
através de um design cuidadoso do sistema de ajuda online
da aplicação.
O objetivo de nossa pesquisa [21] é promover uma nova
perspectiva para o design e uso de sistemas de ajuda online.
Os usuários devem ser capazes de expressar mais
precisamente suas dúvidas e necessidades, e os designers
de antecipar tais dúvidas e necessidades, bem como de
organizar sua resposta apropriadamente.
Nossa abordagem para o design de sistemas de ajuda online
tem como pontos principais de fundamentação a avaliação
de comunicabilidade [14] e a técnica de layering em
documentação minimalista [10]. A avaliação de
comunicabilidade é um método de avaliação de interfaces
que revela – qualitativamente – falhas de comunicação
potenciais que podem ocorrer durante a interação. Como
será visto posteriormente, estas falhas de comunicação são
representadas por expressões coloquiais que os usuários
podem associar a suas necessidades de ajuda.
168
A abordagem minimalista para comunicação técnica sugere
que porções pequenas, mas bastante contextualizadas, de
conteúdo, são a melhor forma de dar informação aos
usuários [5]. O benefício desta abordagem é ainda maior
com o uso da técnica de layering [10], através da qual
pequenas partes de conteúdo minimalista são conectadas e
podem ser acessadas conforme a necessidade do usuário.
Na abordagem aqui descrita, usuários podem escolher uma
dentre um conjunto de expressões disponíveis para indicar
suas dúvidas durante a interação. Fazendo isto eles irão
obter um conteúdo de ajuda contextualizado, associado à
expressão escolhida. Por exemplo, ao não perceber o
retorno (feedback) após a execução de uma ação o usuário
pode escolher a expressão “O que aconteceu?”. Algumas
das expressões utilizadas para acessar a ajuda vêm
diretamente do método de avaliação de comunicabilidade e
outras resultam da análise da literatura de ajuda existente
sobre as dúvidas mais freqüentes dos usuários durante a
interação [4,20]. Poucas delas são encontradas em
aplicações comerciais, como o “O que é isto?” e “Como
faço isto?”. O conjunto atual de expressões sendo usadas
para acesso ao sistema de ajuda online é o seguinte:
• O que é isto?
• Como faço isto?
• Onde está…?
• Para que serve isto?
• E agora?
• A quem isto afeta?
• Por que eu devo fazer isto?
• Onde eu estava?
• De quem isto depende?
• O que aconteceu?
• Quem pode fazer isto?
• Epa!
• Por que não funciona?
• Existe outra maneira de fazer isto?
• Socorro!
Tanto usuários quanto designers são beneficiados com o
uso destas expressões: os usuários têm a chance de
conseguir uma resposta melhor, mais de acordo a suas
necessidades, e os designers têm um princípio de
organização diretamente guiado pelas falhas de
comunicação que eles pretendem atingir ou resolver.
Inspiradas pela técnica de layering [10], nós permitimos
que o usuário primeiro acesse pequenas peças de conteúdo
sobre um determinado elemento de interface ou tarefa,
podendo, depois, aprofundá-las, dependendo de suas
necessidades, até receber as informações desejadas.
Um exemplo simples ilustrando as respostas minimalistas e
o uso recorrente de expressões a partir desta resposta pode
ser visto através do cenário a seguir:
Maria começou um novo emprego hoje, como auxiliar
de escritório. Ela tem conhecimentos básicos de
informática e sua primeira tarefa é criar uma mala
 direta com o endereço da empresa onde trabalha. Só
que isto ela nunca fez…Ela pode até criar uma tabela e
copiar várias vezes o mesmo endereço, mas ela sabe
que existe uma ferramenta própria para isto e vai E agora?
tentar usá-la. E agora?
Para prosseguir você pode imprimir uma (ou

Para iniciar, Maria seleciona, no menu de Arquivos, a
opção de abrir um arquivo novo, pois lembra que é a
partir dali que pode selecionar um template para criar
sua mala direta.
Selecionada a aba desejada, aparece o assistente de
ajuda do Word, com as opções que ela pode escolher.
Maria seleciona a opção desejada (criar uma página
com várias etiquetas iguais) e é apresentada uma
janela para que ela edite sua etiqueta. Maria está
pronta para trabalhar: ela digita uma frase pequena só
para teste e vê que não acontece nada… “E agora?”,
pensa Maria, “Como é que eu faço para seguir
adiante? Como é que eu faço para ver minhas
etiquetas? O que será que posso fazer para
prosseguir?”. Maria resolve pedir por ajuda, clicando
com o botão direito do mouse sobre a área onde ela
acaba de digitar seu texto. Uma janela popup aparece,
mostrando as expressões que ela pode usar sobre o
item indicado. Ela escolhe E agora?, esperando
encontrar informações sobre o que fazer a seguir, dado
que já digitou a informação desejada. Uma mensagem
de ajuda é apresentada, tal como: “Para prosseguir
você pode imprimir uma (ou mais) folha(s) com as
novas etiquetas, criar um novo documento com estas
etiquetas ou alterar as dimensões das etiquetas.”.
Agora Maria tem três opções… Ela quer poder ver as
etiquetas, mas como a única opção disponível que
parece permitir isto é criar um novo documento com as
etiquetas, ela clica com o botão direito do mouse sobre
mais) folha(s) com as novas etiquetas, criar
um novo documento com estas etiquetas ou
alterar as dimensões das etiquetas.
Como faço isto?
Como faço isto?
Para alterar as dimensões da etiqueta você deve
pressionar o botão Opções….
Figura 1: Respostas de Ajuda e Recorrências.
Nossa proposta inclui, também, um módulo de ajuda geral
(à parte, não embutido na aplicação), onde é possível
encontrar informações relacionadas sobre o domínio e a
aplicação como um todo, bem como cenários de uso, para
que designers possam passar sua visão global de design de
uma maneira consistente.
UM MÉTODO PARA CONSTRUÇÃO DE SISTEMAS DE
AJUDA ONLINE
Nesta seção descreveremos os passos na construção de um
sistema de ajuda online: (1) design de IHC considerando-se
questões específicas relacionadas à ajuda; (2) geração do
rascunho do conteúdo da ajuda; (3) refinamento do
conteúdo e especificação dos pontos de recorrência; (4)
construção do módulo de ajuda geral; (5) conexão dos
pontos de acesso à ajuda aos elementos de interface; (6)
testes preliminares; (7) análise de uso durante a avaliação
de comunicabilidade; e (8) refinamento ou redesign do
conteúdo da ajuda. Este método é ilustrado na Figura 2.
Design de IHC
considerando-se as
Modelo de
questões de ajuda Modelo de
Interação +
Aplicação +
ajuda
Modelo de
Usuário +
Modelo de
Tarefas +
ajuda

a expressão criar um novo documento com estas Modelo de

ajuda ajuda Modelo de
Interface +
Domínio +
etiquetas e seleciona a expressão Como faço isto?. A ajuda Geração do rascunho do
conteúdo da ajuda
ajuda

mensagem de ajuda correspondente poderia ser: “Para

criar um novo documento com as etiquetas você deve Rascunho
da ajuda
pressionar o botão Novo documento”.
Refinamento do conteúdo Construção do módulo
Maria segue as instruções, torcendo para conseguir e especificação dos de ajuda geral
pontos de recorrência
terminar logo sua tarefa e conseguir causar uma boa
impressão em seu primeiro dia de trabalho... Módulo de
ajuda geral
Ajuda local +
recorrências

Este cenário pode ser visualizado na Figura 1. Este é um Conexão dos pontos de
acesso à ajuda aos
exemplo fictício, baseado na tarefa de criação de etiquetas elementos de interface

no MS Word®. O conteúdo das respostas de ajuda baseia-

Testes preliminares
se no funcionamento real do Word para esta tarefa e nas
informações de ajuda que o mesmo oferece sobre esta
Análise de uso durante
tarefa (o conteúdo textual da ajuda não foi produzido avaliação de
Refinamento e/ou
comunicabilidade
utilizando nossa abordagem). redesign do
conteúdo da ajuda

Figura 2: O método proposto.

Design de IHC considerando-se as Questões de Ajuda

Um requisito implícito de nossa proposta é que
necessitamos capturar parte da lógica de design (design

169
rationale), tarefa esta que não é fácil [11]. Entretanto,
devemos enfatizar que as únicas porções relevantes desta
lógica para sistemas de ajuda online são aquelas que afetam
diretamente a experiência do usuário. Em outras palavras,
todas as decisões que são relacionadas ao design de
software, sua arquitetura e itens semelhantes, não são
importantes para propósitos da ajuda.
A informação sobre a lógica de design deve ser capturada
durante o processo de design da aplicação. Esta é uma das
razões pelas quais seguimos uma abordagem baseada em
modelos (de fato extensões de modelos conhecidos) para o
design de IHC. Os modelos são estendidos precisamente
por causa da introdução de informações que são específicas
para o design da ajuda.
Em geral, abordagens de IHC baseadas em modelos
promovem a representação de soluções de interação a fim
de ajudar o designer a refletir sobre elas e tomar decisões
adequadas, ou ainda para permitir a geração (semi-)
automática da interface de usuário. Existe uma variedade
de modelos conhecidos: modelos de tarefas são os mais
amplamente utilizados, mas modelos de usuário, domínio,
apresentação e diálogo, entre outros, são também
encontrados na literatura [13,16,17,18]. Após uma série de
estudos sobre estes modelos, a fim de verificar a
possibilidade de utilizá-los como fonte de informações para
o conteúdo da ajuda, foram selecionados os modelos de
domínio, de aplicação, de tarefas, de usuário, de interação e
de interface, os quais foram estendidos para cobrir as
informações de ajuda necessárias.
Tanto as respostas locais de ajuda (abordagem minimalista)
quanto o módulo de ajuda geral são derivados destes
modelos, os quais devem ser construídos durante o período
de design da aplicação.
A seguir será descrito, brevemente, o que cada modelo
deve conter, a fim de conter as informações necessárias à
construção do sistema de ajuda:
• Modelo de Domínio (sobre o domínio da aplicação):
descrição do domínio e da natureza do trabalho nele
realizado, definição detalhada dos signos de domínio,
i.e., conceitos do domínio que são apresentados ou
manipulados pela aplicação ou pelo usuário durante a
interação.
• Modelo de Aplicação (sobre a aplicação (a ser)
implementada): descrição da aplicação, incluindo sua
utilidade, as vantagens de utilizá-la, as atividades que
ela permite realizar, e os signos de aplicação utilizados,
i.e., conceitos que não pertencem ao domínio e que são
introduzidos pela aplicação.
• Modelo de Tarefas (sobre as tarefas que podem ser
realizadas na aplicação): descrição de cada tarefa,
incluindo sua utilidade e a motivação do usuário para
realizá-la (segundo a percepção do designer), tarefas
relacionadas (tarefa-mãe e os relacionamentos com
outras tarefas), condições necessárias para sua
170
execução, e os signos de domínio e de aplicação a ela
associados.
• Modelo de Usuário (sobre os usuários da aplicação):
papéis e perfis, indicando quem pode ou deve realizar
quais tarefas, e quais são as preferências de interação de
cada (classe de) usuário.
• Modelo de Interação (sobre os caminhos de interação
possíveis na aplicação, ou seja, sobre a conversa para
realizar uma determinada tarefa na aplicação):
alternativas de operacionalização possíveis para
execução de cada tarefa. Para cada alternativa:
motivação do usuário para execução (segundo a
percepção do designer), condição para execução,
indicação de preferência de execução (segundo a
percepção do designer), seqüência de ações necessárias
para sua execução. Para cada ação: valor default, forma
de desfazer, conexão com a próxima ação.
• Modelo de Interface (sobre os elementos de interface da
aplicação): tipo de elemento de interface, valores
possíveis, valor default, localização na interface, signos
de domínio ou aplicação a ele associado.
Neste passo enfatizamos a importância de o designer da
ajuda (e/ou equipe responsável pelo desenvolvimento do
sistema de ajuda) participar durante todo o processo de
design da aplicação, no que tange a experiência do usuário,
a fim de capturar a informação necessária à construção do
sistema de ajuda online.
Geração do Rascunho do Conteúdo da Ajuda
Conforme visto anteriormente, deve-se elaborar respostas
minimalistas para cada expressão que um usuário pode
escolher para expressar sua necessidade de ajuda. A fim de
acelerar a geração de um rascunho destas respostas, nosso
método disponibiliza templates de conteúdos de ajuda
associados a cada expressão. Estes templates são
instanciados com informações advindas dos diferentes
modelos de design de IHC. Por exemplo, para a expressão
“O que é isto?”, o conteúdo vem diretamente da descrição
do signo relacionado ao foco da expressão (signo de
domínio ou de aplicação), conforme indicado no modelo
correspondente (de domínio ou de aplicação):
O que é isto?
Resposta: descrição(Signo)
Vale ressaltar neste ponto que a noção de signo é
justamente uma das extensões que fizemos aos modelos
mais tradicionais de domínio e aplicação, com vistas a
apoiar a construção da ajuda online. Um signo é uma
unidade de significação (que pode ser interpretada e usada
para comunicar uma idéia). Assim, por exemplo, são
signos de um domínio de editoração de textos unidades
como ‘documento’ e ‘layout de página’. São signos de uma
aplicação de edição eletrônica de texto como o MS Word®,
por exemplo, unidades como ‘caixa de ferramentas de
controle’ ou ‘layout on-line’.
Uma geração mais elaborada pode ser ilustrada pela
expressão “Como faço isto?”, referente a uma tarefa. Neste
caso, temos o seguinte template de resposta:
tarefa1,
… As porções relativas a informações de domínio e de
Como faço isto? e aplicação deste módulo podem ser construídas e refinadas
pode tarefan.
Resposta: Para tarefa_mãe, você
deve
tarefa1,
… também ser incluída no módulo de ajuda geral.
busca, no modelo de ou
tarefan.
tarefas, as tarefas que
são filhas da tarefa
indicada
[, na ordem que
dependendo da seqüência de você desejar].
operadores de tarefa
relacionados
A partir destes templates e das informações contidas nos
modelos, um rascunho da resposta de ajuda é gerado para
cada par expressão–elemento (signo, tarefa, cursos
alternativos de ação e ações propriamente ditas).
Refinamento do Conteúdo e Especificação das
Recorrências
Tendo sido gerado o rascunho das respostas, o designer da
ajuda necessita selecionar os elementos que – de seu ponto
de vista (baseado em entrevistas com os usuários, análise
de domínio, etc) – devem ter associadas respostas de ajuda
locais (sensíveis ao contexto). Para cada elemento, o
designer da ajuda deverá, também, selecionar uma ou mais
das expressões relacionadas. Em outras palavras, ele
selecionará aqueles elementos sobre os quais ele acredita
que o usuário poderá ter dúvidas ou que ele gostaria de
explicar ou descrever aos usuários, e as expressões que
serão utilizadas para acessar este conteúdo de ajuda.
Logo que estes pares de elemento–expressão são
selecionados, os rascunhos de respostas gerados devem
passar por um processo de refinamento, durante o qual
especialistas em redação técnica trabalharão o texto, a fim
de melhor comunicar a mensagem do designer aos
usuários. Tendo feito isto, cada resposta de ajuda é
analisada, a fim de verificar os possíveis pontos de
recorrência que elas podem conter. Estes pontos indicam os
elementos textuais da resposta que terão expressões e
conteúdo de ajuda associados. Este conteúdo pode, por sua
vez, conter pontos de recorrência adicionais e assim,
sucessivamente, permitindo o aprofundamento das
informações de ajuda sobre determinado tópico.
Este passo pode ser feito antes de a interface ser
implementada, com base nos storyboards construídos
durante o processo de design de IHC.
Construção do Módulo de Ajuda Geral
Este módulo contém informações de ajuda sobre o domínio
e a aplicação, e, também, explicações sobre como
diferentes tipos de ajuda funcionam (geral e local). Além
disso, contém informações sobre elementos de interface (e
171
suas expressões correspondentes) e problemas freqüentes
encontrados fora do contexto da aplicação (por exemplo,
problemas de conexão de rede ou falhas de energia durante
uma tarefa).
pari passu com a construção e refinamento do conteúdo da
ajuda local. Parte do conteúdo de ajuda local gerado pode
Conexão dos Pontos de Acesso à Ajuda aos Elementos
de Interface
Estando o conteúdo da ajuda local (expressões e respostas
correspondentes) e também o módulo geral de ajuda bem
definidos, estes podem ser disponibilizados na interface.
Para cada elemento acessível por expressões associadas
escolhido pelo designer da ajuda, um link ao conteúdo de
ajuda correspondente é adicionado. Este link oferece as
expressões disponíveis para determinado elemento e –
através destas – chega-se às respostas correspondentes.
Estas respostas já foram previamente geradas e refinadas e
são embutidas na aplicação a fim de evitar retardos na
execução. Mais do que isso, este refinamento prévio
possibilita um refinamento manual do rascunho de resposta
gerado, a fim de que o formato das respostas seja mais
natural e sua comunicação mais eficiente.
Um designer gráfico deve trabalhar junto neste passo a fim
de especificar a interface do módulo de ajuda geral, da
ajuda local, e dos elementos de interface que representam
os pontos de conexão à ajuda.
Testes Preliminares
Estando construídos o protótipo da aplicação, o sistema de
ajuda local e o módulo de ajuda geral, a equipe de design
deve promover testes preliminares a fim de verificar se as
expressões e suas respostas correspondentes e, também, as
informações do módulo de ajuda geral, estão consistentes.
Toda conexão de ajuda deve ser testada, bem como todos
os pontos de recorrência das respostas.
Análise de Uso durante Avaliação de Comunicabilidade
Uma vez que a aplicação como um todo esteja
implementada, podem ser efetuados testes com usuários
reais através da avaliação de comunicabilidade [14], para
verificar se a interface está transmitindo realmente a
mensagem pretendida pelo designer e para investigar
problemas que possam ocorrer durante a interação.
Além de analisar a interface como um todo, é possível
aproveitar esta avaliação para analisar a interação
específica com o sistema de ajuda. A fim de melhor
observar a interação durante os testes e de ser capaz de
capturar os problemas que possam ocorrer no uso da ajuda,
é interessante que o designer da ajuda esteja presente
durante as observações, para que ele tenha foco
especificamente nestas questões. Ele pode não somente
observar problemas no acesso às expressões de ajuda e na
compreensão de suas respostas, mas também notar
dificuldades dos usuários que ainda não tenham sido
antecipadas (e portanto não tenham ajuda associada), ou
aquelas respostas que não auxiliam o usuário em seu
problema corrente.
Refinamento e/ou Redesign do Conteúdo da Ajuda
A partir dos resultados de teste, a interface pode ser
refinada ou re-projetada. Isto pode causar a necessidade de
re-projetar o conteúdo da ajuda. Além disto, testes podem
indicar a necessidade de mudanças tanto no conteúdo da
ajuda quanto nas conexões de interface. Depois destes
ajustes, a aplicação deve passar por sessões de testes
adicionais com usuários, e esta iteração continuará até que
maiores problemas não sejam encontrados.
ESTUDO DE CASO: PROJETO ORÉ
Para fins de ilustração descreveremos porções do sistema
de ajuda de uma aplicação, o qual foi projetado e
desenvolvido seguindo o método proposto. A aplicação
deste estudo de caso destina-se a apoiar o trabalho
voluntário em uma organização não governamental [12]. O
módulo desta aplicação que será utilizado como exemplo é
o Quadro de Avisos (Figura 3).
Figura 3: Página principal do módulo Quadro de Avisos.
Como o próprio nome indica este módulo é utilizado como
quadro de avisos virtual da comunidade de membros desta
organização não-governamental. Através do quadro, a
comunidade apresenta à sociedade em geral, via Internet,
avisos relacionados ao seu trabalho e à organização como
um todo, os quais podem ser lidos por qualquer
interessado.
Estes avisos podem ser classificados em diferentes seções,
de acordo com diferentes tópicos ou divisões da
organização. Avisos relacionados à parte administrativa da
organização, por exemplo, encontram-se na seção
“Administração”; avisos relacionados a pedidos e
possibilidades de doações, na seção “Como ajudar”; avisos
relacionados a festas e eventos públicos ocorridos (ou a
ocorrer), na seção Eventos; e, assim, sucessivamente. A
pessoa que utilizar o quadro pode navegar pelas diferentes
seções em busca dos avisos de seu interesse, buscá-los
172
utilizando palavras relacionadas ao mesmo e, também,
ordená-los a fim de facilitar sua busca.
Nem todas as seções do quadro estão disponíveis para toda
a sociedade. Determinadas seções são de interesse apenas
da comunidade (como as que apresentam avisos relativos à
parte administrativa, por exemplo), sendo apresentadas em
uma área privativa, visualizada somente pelos membros da
organização que se cadastraram e que por isto têm
permissão de acesso. Nesta área, além do acesso às seções
privativas, os membros da comunidade podem gerenciar
seus avisos (incluir novos, e alterar ou excluir os
existentes).
Como ilustração dos passos seguidos no método, será
utilizado o seguinte cenário, ilustrado na Figura 4:
Joana, uma nova voluntária, foi informada de que
agora existe um quadro de avisos virtual onde todos os
membros da organização podem colocar avisos
relativos a seus grupos. Para ela, usar um quadro deste
tipo é fácil pois ela usa muito a Internet como fonte de
pesquisa para seus trabalhos de faculdade e como meio
de contato com seus amigos que moram fora do estado.
Disseram a ela que além de ser muito fácil usar o
quadro, se ela tivesse alguma dúvida era só clicar no
ponto de interrogação azul, através do qual ela obteria
ajuda imediatamente. Ela decide verificar o quadro
para ver como ele funciona… Logo na entrada ela vê
algumas mensagens sob o título “Destaques”. “Uhm,
existe um pequeno ponto de interrogação aqui”, nota
Joana. Ela decide ver a explicação e aprende que
aquele título (“Destaques”) indica qual é a seção
corrente. Como a palavra “seção” estava destacada,
ela decide clicar nela para ver o que acontece. “Legal,
aqui explica que as seções são utilizadas para
podermos separar os avisos que são relacionados!”.
Assim ela vai diretamente a seção eventos para
verificar quais serão os próximos eventos da
organização...
Figura 4: Acessos à ajuda e respostas relacionadas.
A seguir será descrita, passo a passo, a utilização do
método proposto na construção do sistema de ajuda online
da aplicação em questão.
Modelos de Design de IHC e as Informações de Ajuda
Na aplicação usada como ilustração de utilização deste
método, o primeiro passo realizado foi a análise de domínio
e de usuário, através de entrevistas abertas com membros
representativos da organização [1]. Depois de a análise ter
sido concluída, foram construídos os cenários, os modelos
de tarefa e de interação e os storyboards, segundo a
abordagem proposta em [3]. E, em paralelo a isto, o
designer da ajuda instanciou as informações coletadas a
partir destas análises e modelagem nos modelos descritos
na seção que descreve o método.
O designer da ajuda foi um membro ativo durante todo o
processo de design. Sua presença foi essencial para
assegurar a captura das informações específicas de ajuda
necessárias e armazenar estas informações na base de
dados correspondente que, no final do processo, continha
todas as informações necessárias para a geração do
rascunho do conteúdo da ajuda. Desta forma, o processo de
design da ajuda foi mais eficiente e deu melhores
resultados, dado que a informação não refletia somente o
produto do design, mas incluía também a lógica de design
por trás de decisões relevantes. Se estas informações não
tivessem sido capturadas durante o processo de design,
muitas delas poderiam ter sido perdidas ou esquecidas.
Como ilustração deste passo, considere uma parte do
modelo de domínio, relacionado a um signo de domínio:
SIGNO DE DOMÍNIO Seção{
DESCRIÇÃO(Uma seção é o lugar onde os
avisos são agrupados de acordo
com seu assunto.)
UTILIDADE(Para classificar os avisos que têm
características comuns, facilitando
sua localização. Por exemplo, avisos
sobre eventos encontram-se na
seção Eventos, sobre voluntários, na
seção Voluntários, e assim
sucessivamente.)
} Tendo sido gerado o rascunho das respostas para todas as
… combinações expressão–elemento, o primeiro passo de
uma parte do modelo de aplicação, relacionado a um signo
de aplicação:
SIGNO DE APLICAÇÃO Indicador da Seção Atual{
DESCRIÇÃO(Este é o indicador de qual é a
seção atual (seção Quadro Geral ou
seção Como ajudar, por exemplo).
Uma seção pode ser pública o
privativa da comunidade.)
UTILIDADE(Para indicar qual a seção que está
sendo apresentada no momento.)
} refinado e analisado mais uma vez, com o propósito de
...
e uma porção do modelo de tarefas:
173
TAREFA Fornecer os dados necessários{
TAREFA-MÃE(Criar um aviso)
OPERADOR seqüência
SEQÜÊNCIA 1
SIGNO DE DOMÍNIO(autor título data seção
chamada aviso prazo)
SIGNO DE APLICAÇÃO(quadro_geral login)
}
TAREFA Incluir o aviso{
TAREFA-MÃE(Criar um aviso)
OPERADOR seqüência
SEQÜÊNCIA 2
}
...
Geração do Conteúdo da Ajuda
O rascunho das respostas de ajuda foi gerado
automaticamente a partir das informações contidas na base
de dados derivada dos modelos de design. A partir desta
geração, o designer da ajuda selecionou quais respostas
deveriam realmente ser incluídas na aplicação.
Considere-se o indicador da seção corrente, “Destaques”.
Este indicador é um signo de domínio, e as expressões
relacionadas a signos (tanto de domínio quanto de
aplicação) são: “O que é isto?”, “Para que serve isto?” e
“Onde está?”. Tomando como exemplo a expressão “O que
é isto?” e usando o template mencionado anteriormente, o
elemento descrição é buscado do componente de signos de
domínio, do modelo de domínio, resultando no seguinte
rascunho de resposta:
Este é o indicador de qual é a seção atual (seção
Quadro geral, ou seção Como ajudar, por exemplo).
Outro exemplo, este relacionado ao modelo de tarefas, seria
a resposta para a expressão “Como faço isto?”, relacionada
à tarefa “Criar um aviso”. Utilizando o template indicado, e
buscando as tarefas que têm “Criar um aviso” como tarefa-
mãe, o rascunho resultante seria:
Para criar um aviso, você deve fornecer os dados
necessários e incluir o aviso.
Refinamento do Conteúdo e Especificação das
Recorrências
refinamento foi selecionar quais destas combinações
seriam, de fato, incluídas no sistema.
No exemplo apresentado na Figura 4, a expressão “Para
que serve isto?” está também relacionada a um signo de
domínio (no caso, “Indicador de seção atual”). Entretanto,
foi decisão do designer não incluir esta expressão, porque,
neste caso particular, sua resposta seria redundante com a
resposta dada à expressão “O que é isto?”.
O rascunho do texto das respostas selecionadas foi então
encontrar pontos de recorrência possíveis.
No exemplo trabalhado, na resposta à expressão “O que é
isto?”:
 Este é o indicador de qual é a seção atual (seção
Quadro geral, ou seção Como ajudar, por exemplo).
o designer verificou referência a outro signo de domínio,
no caso, “seção”. Ele selecionou esta palavra como um
ponto de recorrência na resposta, e associou as expressões
“O que é isto?” e “Para que serve isto?” a ele.
O template para a expressão “O que é isto?” de um signo
de domínio é o seguinte:
descrição(Signo)
e o template para a expressão “Para que serve isto?” é:
utilidade(Signo)
Então, a resposta à expressão “O que é isto?” é:
Uma seção é o lugar onde os avisos são agrupados de
acordo com seu assunto.
E a resposta para a expressão “Para que serve isto?”:
Para classificar os avisos que têm características
comuns, facilitando sua localização. Por exemplo,
avisos sobre eventos encontram-se na seção Eventos,
sobre voluntários, na seção Voluntários, e assim
sucessivamente.
Estas respostas já faziam parte do rascunho inicial de
respostas gerado, e foram, então, refinadas e analisadas
para inclusão de possíveis pontos de recorrência.
Construção do Módulo de Ajuda Geral
O módulo de ajuda geral da aplicação usada como estudo
de caso aparece em uma nova janela (Figura 5). Assim o
usuário pode ver ambas as janelas – aplicação e sistema de
ajuda – simultaneamente.
Figura 5: Módulo de ajuda geral.
Cinco seções foram projetadas para este módulo:
• informações sobre os tipos de ajuda disponíveis;
• informações sobre o domínio no qual a aplicação
está inserida;
• detalhes sobre a aplicação em si;
• uma versão completa das expressões e pontos de
recorrência para ajuda local, apresentados
seqüencialmente e com links de hipertexto;
174
• informações sobre problemas de conexão de rede
que podem ocorrer durante a interação.
Conexão aos Elementos de Interface
Para esta aplicação, o designer gráfico criou um símbolo a
ser disposto junto aos elementos de interface onde deseja-
se disponibilizar acesso à ajuda local, para funcionar como
um link para este acesso. O símbolo escolhido foi um ponto
de interrogação com uma borda quadrangular (destacado na
Figura 6).
Figure 6: Link de acesso à ajuda local.
Tendo sido definidos os elementos que têm ajudas locais
associadas, seus links foram implementados na interface.
As requisições de ajuda locais que podem estar disponíveis
neste formato são aquelas relacionadas a signos e/ou
tarefas. Os demais elementos são referenciados através dos
pontos de recorrência encontrados dentro das respostas
fornecidas.
Testes Preliminares
Foi feita a verificação de todos os acessos à ajuda da
aplicação – tanto através da interface quanto de
recorrências – pelo designer da ajuda e outros membros da
equipe, a fim de detectar erros possíveis. Alguns poucos
problemas foram detectados, como falta de chamadas de
ajuda locais ou inconsistências nos pontos de recorrência,
os quais foram rapidamente corrigidos e testados
novamente.
Análises mais aprofundadas foram também efetuadas, a fim
de verificar se os textos da ajuda estavam ambíguos,
levando o usuário a interpretações equivocadas.
Análise de Uso durante Avaliação de Comunicabilidade
Quando o primeiro protótipo da aplicação ficou pronto para
teste, algumas sessões de avaliação de comunicabilidade
foram efetuadas com seis usuários reais, selecionados
especificamente por representarem o perfil geral da maioria
da população-alvo de usuários, como havia sido indicado
pela análise das entrevistas. Dois deles tinham muito pouco
conhecimento computacional, três deles eventualmente
usavam computadores para propósitos pessoais e um tinha
bastante experiência.
Do ponto de vista do designer este passo tornou possível
determinar problemas na ajuda, os quais podem ser
agrupados em três classes: conteúdo da ajuda, o declinar da
ajuda e cultura de uso da ajuda.
Conteúdo da Ajuda
Durante os testes, o designer da ajuda observou que os
usuários tinham problemas em situações não previstas por
ele, o que significava que a ajuda correspondente era
inadequada ou não tinha sido implementada. Não existiam,
por exemplo, explicações sobre as diferenças entre seções
públicas e privadas do Quadro de Avisos, ou sobre os
critérios disponíveis para busca.
O Declinar da Ajuda
Uma observação interessante durante os testes foi que um
usuário, depois de muitas tentativas infrutíferas em usar os
mecanismos de busca da aplicação, fez uso da ajuda local.
Ele leu a explicação e espontaneamente disse que entendeu
o que deveria ser feito. Porém, mesmo assim, decidiu fazer
algo diferente do que está detalhado na ajuda, o que acabou
impedindo-o de conseguir executar a tarefa definida no
cenário de teste.
Cultura de Uso da Ajuda
O designer da ajuda também notou que, independente do
grau de conhecimento que os usuários tivessem sobre o
domínio da aplicação ou sobre o uso de computadores em
geral, a maioria deles não acessou a ajuda. Não existe uma
cultura de buscar por ajuda online quando acontece algum
problema. Poucos foram aqueles que buscaram por ajuda e,
quando o fizeram, parecia que tinham feito isso de forma
arbitrária, porque logo fechavam a janela de ajuda sem que
tivesse havido tempo suficiente para ler as informações
apresentadas. Ou, como no caso anterior, liam a
informação mas não procediam como indicado. Um único
usuário leu o texto da ajuda e seguiu a explicação sugerida.
Refinamento e/ou Redesign do Conteúdo da Ajuda
A partir das observações feitas durante os testes, as
respostas de ajuda necessárias foram refinadas, o que
resultou, também, no refinamento dos modelos de design
envolvidos. Por exemplo, a resposta de ajuda para o signo
de domínio “seção” foi ajustada, e uma nova resposta de
ajuda foi criada para responder aos problemas descritos em
Conteúdo da Ajuda, sobre seções públicas e privadas
(figura 7).
Figura 7: Respostas de ajuda revisadas e novas.
Atualmente, o designer de ajuda está analisando
alternativas para criar uma cultura de acesso (bem como
leitura e consideração) à ajuda na organização em questão.
A maioria das dúvidas que os usuários tiveram durante os
175
testes teria sido facilmente eliminada se eles tivessem
consultado a ajuda local correspondente.
CONSIDERAÇÕES FINAIS
Neste artigo, mostramos porque, para a Engenharia
Semiótica, o sistema de ajuda online é uma parte essencial
da aplicação. É através da ajuda que o designer pode falar
diretamente aos usuários da aplicação, mostrando as razões
por trás de seu design e como os usuários podem fazer um
uso melhor desta.
Os usuários podem, por sua vez, expressar suas dúvidas
mais diretamente usando uma das expressões de acesso à
ajuda local, durante a interação. A resposta será um
fragmento do ponto de vista e lógica de design do designer,
enquanto este estava projetando a aplicação. Além disto, os
usuários podem aprofundar suas questões através dos
pontos de recorrência disponíveis em cada resposta de
ajuda, em uma infinita cadeia de associações, guiada por
suas necessidades. Este processo é associado a alguns dos
conceitos fundamentais na teoria semiótica, os conceitos de
semiose (uma cadeia indefinidamente longa de associação
de signos disparada por um signo inicial) e de abdução (um
tipo especial de inferência, que mistura elementos do
raciocínio indutivo e do dedutivo).
O método apresentado neste artigo facilita o design do
sistema de ajuda online sob esta perspectiva. E o custo de
sua construção é reduzido seguindo-se um design de
interfaces baseado em modelos. Isto permite, por um lado,
que mesmo as versões beta de aplicações em
desenvolvimento já tragam um componente de ajuda online
para apoiar os usuários iniciais que tipicamente determinam
a adoção da tecnologia. Por outro, legitima a ajuda online
como parte integrante de uma aplicação e não como um
último e derradeiro apêndice, adicionado às pressas
somente à versão que ‘vai para as prateleiras’.
Para a Engenharia Semiótica em particular, o design
baseado em modelos é muito importante porque possibilita
manter a consistência entre os produtos de design
construídos a cada fase. Isto permite ao designer criar e
enviar uma mensagem coesa aos usuários, a fim de
aumentar as chances destes de entender sua mensagem.
Além dos esforços técnicos e teóricos, devemos ter uma
atenção redobrada na introdução de mudanças na maneira
que os usuários percebem a ajuda. Como uma regra,
usuários acessam a ajuda somente como um último recurso
[6]. As razões para isto não devem ser enunciadas com
precipitação, pois podem estar ligadas a vários fatores
dentre os quais destacamos dois.
Em primeiro lugar, eles podem ter tido experiências
frustrantes no passado, ou até nem entenderem qual a
utilidade de um sistema de ajuda. Esta experiência pode
reforçar uma atitude negativa a priori em relação a todo e
qualquer sistema de ajuda. Contribuem para este
diagnóstico as abundantes evidências da qualidade muito
ruim dos sistemas de ajuda oferecidos pela maioria das
aplicações de software contemporâneas.
Mas, em segundo lugar, isto pode estar associado a causas
mais profundas, muito bem retratadas por Robert Pirsig em
seu famoso romance publicado nos anos 70 – Zen e a arte
de manutenção de motocicletas [14]. Uma colagem do
texto do capítulo inicial do livro, em que o narrador faz
observações sobre o comportamento do amigo que realiza
com ele um passeio de motocicleta pelo interior dos
Estados Unidos, nos ajuda a chegar ao ponto desta
discussão.
Parece-me natural e normal fazer uso dos
pequenos estojos de ferramentas e manuais de
instrução que vêm com a máquina [...]. John,
porém, não concorda. Prefere entregar a moto
a um mecânico competente [...]. [...] uma vez,
[...] num dia de calor infernal, [...] vejo o John
acionando repetidamente o pedal do kick. O
fedor de gasolina é tão forte que dir-se-ia
estarmos ao lado de uma refinaria. Eu digo isto
a ele, achando que é suficiente para informá-lo
de que o motor está afogado.
[...]
- A máquina não tem razão nenhuma para
não pegar. É novinha em folha, eu sigo as
instruções ao pé da letra. Veja, está com o
afogador aberto, como eles recomendam.
- Afogador aberto?
- É o que recomendam as instruções.
- Isto a gente faz quando o motor está frio!
- Mas estivemos no bar uma meia hora pelo
menos – justifica ele.
[...]
- John, hoje está quente. O motor leva mais
tempo para esfriar mesmo num dia gelado.
5. Carroll, J.C. (ed.) (1998) Minimalism Beyond the
Nurnberg Funnel. Cambridge, The MIT Press,
Cambridge.
6. Ceaparu, I., Lazar, J., Bessiere, K., Robinson, J.,
Shneiderman, B. (2002) Determining Causes and
Severity of End-User Frustration. Technical Report,
HCIL-2002-11, CS-TR-4371, UMIACS-TR-2002-51
[ftp://ftp.cs.umd.edu/pub/hcil/Reports-Abstracts-Bibliography/2002-
11html/2002-11.pdf, visited September 2002]
7. de Souza, C.S. (1993) The Semiotic Engineering of
User Interface Languages. International Journal of
Man-Machine Studies, 39, 753-773.
8. de Souza, C. S., Prates, R. O. e Barbosa, S. D. J. (2003)
“Adopting information technology as a first step in
design”. Interactions Volume 10 , Issue 2 March +
April 2003 Pages: 72 - 79
9. de Souza, C.S., Prates, R. e Carey, T. (2000) Missing
and Declining Affordances: are these appropriate
concepts?. Journal of the Brazilian Computer Society,
Number 1, Volume 7, July 2000. pp.26-33.
10. Farkas, D.K. (1998) Layering as a Safety Net for
Minimalist Documentation. Carroll, J.C. (ed.)
Minimalism Beyond the Nurnberg Funnel. Cambridge,
The MIT Press, Cambridge.
11. Moran, T.P. and Carroll, J.M. (1996) Design Rationale:
Concepts, Techniques, and Use. Mahwah, NJ.
Lawrence Erlbaum and Associates.
12. ORÉ, Projeto (2002). In: http://serg.inf.puc-rio.br/ore.
177
13. Paternò, F. (1999) Model-Based Design of Interactive
Applications, Londres, Springer-Verlag.
14. Pirsig, R. (1984) Zen e a arte de manutenção de
motocicletas. Edição Brasileira. Rio de Janeiro, RJ. Paz
e Terra
15. Prates, R.O., de Souza, C.S., Barbosa, S.D.J. (2000) A
Method for Evaluating the Communicability of User
Interfaces. ACM Interactions, 31–38. Jan-Feb 2000.
16. Preece, J., Rogers, Y., Sharp, E., Benyon, D., Holland,
S., Carey, T. (1994). Human-Computer Interaction.
Reading, Addison-Wesley.
17. Puerta, A. (1996) The Mecano Project: Comprehensive
and Integrated Support for Model-Based Interface
Development. Vanderdonckt, J. (ed) Computer-Aided
Design of User Interfaces. Namur, Presses
Universitaires de Namur.
18. Puerta, A. (1997) A Model-Based Interface
Development Environment, IEEE Software, 14(4),
July/August, pp.41-47.
19. Purchase, H; Worrill, J. (2002) An empirical study of
on-line help design: features and principals. Int. J.
Human-Computer Studies 56, 539-567.
20. Sellen, A.; Nicol, A. (1990). Building User-Centered
On-line Help. In Laurel, B. The Art of Human-
Computer Interface Design. Reading: Addison-Wesley.
21. Silveira, M.S.; Barbosa, S.D.J.; de Souza, C.S. (2001)
Augmenting the Affordance of Online Help Content.
Proceedings of IHM-HCI 2001, Lille, Springer-Verlag.