CEESA – CENTRO DE EDUCAÇÃO EXPONENCIAL SA

FIE – FACULDADE EXPONENCIAL

ARTIGO INTERACTION PATTERNS IN USER INTERFACES

PADRÕES DE INTERAÇÃO EM INTERFACES DE USUÁRIOS
(Warning, Hinting, Mode Cursor, List Browser, Continuous Filter)

ANDRE GEIER MENDES

FABIANO BORGES DA SILVA
JOSE PIGNAT FILHO
MARCELO FORTES
Sistemas de Informação
Ergonomia de Software

Chapecó SC – Abril de 2005

Centro Educacional Exponencial SA
FIE – Faculdade Exponencial
Ciências Exatas e da Terra
Curso: Sistema de Informação
Disciplina: Ergonomia de Software
Professor: Danton Cavalcanti Franco Junior
Período: 7°
Semestre: 2005/1

ARTIGO INTERACTION PATTERNS IN USER INTERFACES

PADRÕES DE INTERAÇÃO EM INTERFACES DE USUÁRIOS
(Warning, Hinting, Mode Cursor, List Browser, Continuous Filter)

Andre Geier Mendes

Fabiano Borges Da Silva
Jose Pignat Filho
Marcelo Fortes

Chapecó SC, Abril de 2005

 SUMÁRIO

1.ABSTRACT........................................... ........................................4
2.INTRODUÇÃO..................................................... ..........................4
3.FALANDO NA PERSPECTIVA DO USUÁRIO.........................................5
4.CATEGORIZANDO PROBLEMAS DO USUÁRIO.....................................6
5.UM FOCO NA USABILIDADE...................................... ......................7
6.USANDO FRAGMENTOS DE MODELO UI EM PADRÕES DE UID............11
7.ESTRUTURANDO A COLEÇÃO........................................................12
WARNING.................................................. ...................................14
HINTING.......................................................................... .............16
MODE CURSOR.................................................... ..........................18
LIST BROWSER................................................................... ...........20
CONTINUOUS FILTER......................................................... .............23

-3-
 PADRÕES DE INTERAÇÃO EM INTERFACES DE USUÁRIOS

1. ABSTRACT

Este artigo discute e apresenta padrões de interação nas interfaces do

usuário. Estes padrões são focados nas soluções para os problemas que os
usuários finais tem ao interagir com sistemas.
Os padrões levam uma perspectiva ao usuário final da condução para
formatos onde á usabilidade é a qualidade essencial. O formato é
discutido e apresentado ao longo de vinte padrões escritos em tais
formatos.

2. INTRODUÇÃO

Os padrões apresentados neste artigo são parte de um esforço

contínuo para descrever soluções de sucesso que beneficiem os usuários
de sistemas. Conseqüentemente, estas são soluções que na maioria
estamos familiarizados.
Outras coleções como Common Ground (Tidwell 1998) ou a Web
Patterns Collection (Perzel e Kane 1999) não fazem a distinção explícita
entra a perspective do usuário ou a perspectiva do designer. Embora
alguns desses padrões beneficiam os usuários, eles fogem do propósito e
a razão para isto. Por exemplo, a indicação do problema em testes
padrões de Tidwell é tipicamente do formulário, “Como pode o melhor
produto mostrar....” que não se relaciona explicitamente á um problema
de uso do usuário.
Geralmente falando, cada padrão está focado na perspectiva do
usuário, é também usando na perspectiva do designers, mas não vice-
versa. Conseqüentemente, nossos padrões devem beneficiar designers e
usuários finais.
O interesse em padrões de interface com os usuários (UID) vem
desde 1994 (Rijken 1994, Bayle 1998) mas, embora vários padrões

-4-
existam, á uma aceitação que direciona para um padrão semelhante, isto
é, Padrões de linguagem, que não emergiram ainda.
Estes parecem ser á volta do consenso sobre o formato e foco em
padrões para UID. Conseqüentemente, um padrão de linguagem para UID,
não foi estabelecido desde que necessariamente foi precedido pelo
desenvolvimento de uma grande massa de padrões escritos com o mesmo
foco da “visão”.
É nossa opiniãoque padrões em UID requerem um formato especial
que seja focalizado na usabilidade( Van Welie, Vander Veer, e Eliens 1999,
Hartson 1998).

3. FALANDO NA PERSPECTIVA DO USUÁRIO

Quando falamos em perspectivas de usuário, isto torna-se

importante para por ênfase no argumento para como e porque a
usabilidade é melhorada. Sem tal razão é impossível se ver o porque é
realmente uma solução boa e uma solução aceita.
Certas soluções em UID resolvem problemas que designers ou
pessoas de marketing tem, mas não necessariamente resolvem os
problemas que os usuários possuem.
Por exemplo, banners e telas screens são aceitas pelos designers,
mas dificilmente são usuais. Não é difícil para identificar padrões em
interfaces de usuários, mas é difícil de identificar esses padrões que
realmente vão beneficiar os usuários como explica os aspectos da
usabilidade.
Estes são muitos exemplos de uma desorganização nos designers de
interfaces de usuários, ficando difícil de se identificar uma boa solução.
Por outro lado, exemplos ruins podem ser muito úteis aos designers para
usar como padrões, similares a idéia de anti-padrões.
O “interface Hall of Shame”, é um agradável comentário sobre tais
exemplos ruins. Em outros casos está tentando-se descrever soluções que
são minimizadas com a usabilidade relacionando problemas com o usuário

-5-
 Por exemplo, validando dados depois que um usuário tem entrando
não é a melhor solução, embora freqüentemente usada; Não deveria ser
permitido ao usuário entrar com dados sintaticamente incorretos em
primeiro lugar!!. Os formatos ambíguos poderiam ser usados para atingir
esta meta.

4. CATEGORIZANDO PROBLEMAS DO USUÁRIO

Nossos padrões são tarefas relatadas e neste artigo nós

categorizamos de acordo com o tipo de problema de uso que eles se
dirigem. Em (Normann 1988) são sugeridos vários tipos de interface de
usuários. Os princípios dão uma indicação do tipo de problemas e
perguntas (Mckay 1999) os usuários podem ter ao interagir com um
sistema.
• Visibilidade, dá para o usuário á habilidade para entender como o
usar algo apenas olhando. Humm, eu penso que este poder da
característica o faz....
• Fornecer, invulnerabilidade em perceber uma propriedade atual de
um objeto que sugere como o objeto deva ser usado. Agora como
este objeto trabalha??? Oh, eu adquiro isto.....
• Mapeamento Natural, Cria uma relação clara entre o que o
usuário quer fazer e qual mecanismo poderá fazê-lo. Para executar
minha tarefa, eu preciso selecionar esta opção, entre naquela
informação, e então pressione este botão…
• Constraints, reduz o número de modos para executar uma
determinada tarefa e a quantia de conhecimento necessário para
executá-la, enquanto fazendo isto será mais fácil de entender. Oh
não, o que eu tenho para entrar aqui??? Ok, eu tenho estas
escolhas....
• Modelo Conceitual: Um bom modelo conceitual é um no qual os
usuários entendem de que maneira algo pode trabalhar
correspondendo para um caminho que realmente trabalha. Este

-6-
 caminho o usuário pode confiar os efeitos das ações dele. Para
executar a tarefa, eu provejo a informação necessária e dei este
comando… e isto parece trabalhar como eu espero...
• Retorno, Indica ao usuário que uma tarefa está sendo terminada e
que a tarefa acabou corretamente.

Estes princípios supõem que os usuários exibem sempre o

comportamento inteiramente racional. Na prática, os usuários fazem
erros e fazem coisas que não querem realmente fazer.
Conseqüentemente, os princípios adicionais são:
• Segurança, O usuário necessita ser protegido contra as ações não
intencionais ou enganos. Oops! Eu cometi um erro e como é que
eu corrijo isto. Agora eu entendo e eu tentarei novamente.
• Flexibilidade, Os usuários podem mudar seu modo de pensar e
cada usuário pode fazer a coisa diferentemente. Agora que eu penso
sobre ela, esse parâmetro deve ter sido... Cancele-o, eu quero
mudar a ordem.
Como pode ser observado, perguntas sobre as categorias são
bastante gerais e em nossos padrões a descrição do contexto é
importante para distinguirmos as situações em que devemos usar
padrões. Adicionalmente, estes problemas podem ser resolvidos com
várias soluções que fazem isto mais importante até mesmo para ser
preciso e concreto.

5. UM FOCO NA USABILIDADE

Se nós focarmos nos problemas de usabilidade do usuário, nós

precisamos trabalhar com outras implicações como o modo em que nós
escrevemos padrões.
Um padrão para UID deveria focar em soluções que melhoram a
usabilidade de um sistema em uso, que deve ser mensurado por
indicadores de uso.

-7-
 Usabilidade pode ser medida com os seguintes indicadores de uso;
Leitura, memorização, velocidade de performance, taxa de erro,
satisfação, e conclusão da tarefa (Van Welie, Van der Veer, e Eliëns 1999).
Cada teste padrão deve conseqüentemente indicar o impacto nestes
indicadores de uso. Em resumo, se "um teste padrão UID" não melhorar
ao menos um indicador do uso, este não é um teste padrão de UID.
Nós acreditamos que os testes padrões de UID usam um certo
princípio ergonômico e a razão da seção deveria explicar como o princípio
ergonômico está sendo usado na solução de uma melhoria dos indicadores
de uso. A maioria dos elementos comuns do teste, podem ser usados
diretamente para testes padrões de UID também.

Em nossos testes padrões nós usamos os seguintes elementos:

• Problema: São relacionados problemas de uso do sistema e que

são pertinente ao usuário ou qualquer outro stakeholder isso está
explícito na usabilidade. Em contraste com padrões de SE,
problemas em padrões de UID não deveriam ser focalizados nos
problemas de construção enfrentados pelos designers.
Conseqüentemente descrições do problema deveriam ser tarefa do
usuário freqüentemente orientado. Que cairá em uma das categorias
definidas por Norman.

• Princípio da Usabilidade: Padrões de interação normalmente

utilizam solução baseadas em ' princípio'.Um jogo completo dos
princípios não é sabido ainda mas um jogo inicial pode ser dado. A
seguinte lista de usabilidade de princípios são usados, se agrupado
de acordo com Norman (Norman 1988) as categorias de problema
de usuário:

-8-
 Visibilidade: Orientação de usuário, agrupamento, com incremento
esclarecedor,
 Affordance (fornecer): Metáforas
 Mapeamento Natural: Compatibilidade
 Constraints: Minimizar as Ações, auto-explicativo
 Modelos Conceituais: Significado dos códigos, compatibilidade,
Adaptabilidade,
 Avaliação: Avaliação imediata, Legibilidade,
 Segurança : Prevenção de erro, Correção de Erro.
 Flexibilidade : Controle explícito

Contexto. O contexto também é focado no usuário. Quais são as

características de uso do contexto, em termos de tarefas, usuários e
ambiente para o qual pode ser aplicado o padrão?

Solução. Uma solução deve ser descrita muito minuciosamente e não

deve impor novos problemas. Porém, uma solução descreve só o centro
da solução e poderia ser preciso outros padrões para resolver sub-
problemas. Outros padrões pertinentes à solução deveriam ser
referenciados.

Razão. Esta seção descreve como o padrão na verdade trabalha, por que
trabalha, e por que é bom.
A seção de soluções descreve a estrutura visível e comportamentos
do sistema, enquanto a razão provê perspicácia dentro da estrutura e
mecanismos fundamentais que estão debaixo da superfície do sistema.
A razão deve prover uma argumentação razoável para o impacto
especificado na usabilidade quando o padrão for aplicado. Esta seção
também descreve o impacto que o padrão está usando usabilidade quando

-9-
for aplicado. Descreve isso que foram melhorados aspectos de
usabilidade, e qual deles ficaram piores. É habitual que um padrão
aperfeiçoa um ou dois aspectos enquanto outros aspectos tiverem que
sofrer. Cada solução tenta prover o equilíbrio no contexto especificado.
Literatura de Usabilidade identificou os seguintes aspectos
mensuráveis:

• Desempenho de Velocidade: Como os usuários rápidos podem

trabalhar com o sistema.
• Aprendizado: Como é fácil aprender o sistema.
• Memorização: Como os usuários se lembram de como usar o
sistema.
• Satisfação: A satisfação dos usuários ao usar o sistema.
• Tarefas concluídas: Quanto da tarefa poderia ser completado.
• Erros: O número de erros que o usuários fez.

Exemplos, O exemplo deveria mostrar como o padrão foi

prosperamente usado em um sistema. Um exemplo pode ser dado usando
freqüentemente um screenshot e algum texto adicional para explicar o
contexto do particular da solução. É preferível usar exemplos de sistemas
da vida real de forma que a validade do padrão é obrigatória. Se um
escritor não puder achar nenhum exemplo da vida real, o padrão não é
um padrão. Os campos e " visão " precisadas escrever padrões de UID são
importantes.
Além disso, o conhecimento de design sobre " como usar controles "
depende do contexto de quando é aplicado, os usuários e a tarefa
deles/delas. Em outros palavras, está olhando para o problema do ponto
da solução sem saber o problema. Outra adição que nós usamos em
vários padrões é uma " seção de exemplos de contagem". Isto é um,

- 10 -
exemplo de uma real aplicação quando o padrão deveria ter sido aplicado
mas não foi ter sido aplicado. Cria um tipo de efeito de anti-padrão como
saques como uma motivação extra para uso do padrão.

6. USANDO FRAGMENTOS DE MODELO UI EM PADRÕES DE UID

Similar aos padrões de Engenharia de Software, o padrão UID lá

fora, necessita ambos de abstrações e precisa descrições
Um padrão está focado na essência de um problema e sua solução,
e resume aspectos fora do design que é coincidente e irrelevante se
dirigido ao problema e a solução.
Para padrões de SE, o uso de classe e diagramas de colaboração
são bem aceitos para esse propósito.
Porém, padrões de UID precisam de diferentes representações, e o
usuário cria representação de design como instantâneos, storyboards e
esboços são problemáticos, desde que elas são representações de
superfície que faltam a abstração e precisão.
Interface de usuário que modela linguagens por outro lado, suporte
explícito, representações semiformais de " muitos " aspectos do design ao
longo do processo, e provê abstração e precisão Conseqüentemente,
fragmentos de modelagem UI podem ser muito úteis ao formular padrões
de interação.
Para nossa coleção de padrões nós começamos a desenvolver uma
notação que é satisfatória para uso em padrões de UID, e acreditamos seu
usado pode ter vários benefícios de interação dos padrões.

1. Ao formular o padrão inicialmente, nos usamos ajuda de padrões

escritos para abstração particular de aspectos irrelevantes e focaliza no
centro da solução.
2. Quando classificados os padrões, ajuda a ver o que precisava ser
direcionado

- 11 -
3. Quando selecionando padrões isto ajuda ver se o padrão é aplicável
para os problemas que um desenhista está enfrentando.

4. Quando aplicado a solução de padrão, a precisão dos fragmentos faz

com que facilite a aplicação da solução dentro um contexto particular.
Pode ajudar até mesmo na implementação atual da interface de usuário.

7. ESTRUTURANDO A COLEÇÃO

Nós consideramos a coleção de padrão apresentada aqui como um

ponto de partida para um padrão de linguagem. Os padrões nesta coleção
é unida e conseqüentemente forma uma rede de padrões. Além do fato
que é referência de padrão para outros padrões, padrões também
poderiam ser categorizados. Para padrões em UID vários
principios/categorias já tem sido sugeridas.(Mahemoff e Johnston 1998).
Mahemoff propõe as categorias seguintes: tarefa de padrões
relacionados, padrões relacionados ao usuário, padrões de elementos de
interface de usuários e sistema baseados em padrões.
Um categorização da estrutura de uma coleção de padrões e facilidade
de seleção e entendimento e padrões da coleção inteira.
Podem ser usados por eles como padrões para aprender sobre design
mas também como material de referência quando haver uma necessidade.
Nós consideramos a razão posterior mais pertinente e determinou o
modo que nós escrevemos abaixo os padrões. Nós pensamos a razão por
que um desenhista quer procurar um padrão, deveria determinar a ótima
estrutura de fato da coleção de padrão. Para nossa coleção, várias
alternativas são plausíveis. Por exemplo, o desenhista poderia querer
enviar um problema particular ou ele poderia estar procurando um padrão
que de perto emparelha um contexto especificado.
Outro possível índice são o princípio da usabilidade, os indicadores de
uso que são envolvidos, ou padrões que só enviam de aspectos
presentes.

- 12 -
 Em nosso website, nós usamos XML para descrever padrões que
facilitam vários ' visões na coleção e o desenhista poderia usar uma visão
que é apropriada. Desde então não muitos padrões de design de interação
existem e eles quase não foram usados, nós consideramos isto prematuro
resolver em uma estrutura particular. Então, nós apresentamos os padrões
simplesmente como uma coleção unida.

- 13 -
 WARNING

PROBLEMA: O usuário pode involuntariamente causar uma situação de

problema que necessite ser resolvido.

PRINCÍPIO DA USABILIDADE : Prevenção do Erro (Segurança).

CONTEXTO: Situações onde o usuário executa uma ação que possa

involuntariamente conduzir a um problema.

SITUÇÕES:

• O trabalho pode ser perdido se a ação for terminada inesperadamente.

• O Sistema não poder resolver automaticamente essa situação sem que
o usuário seja consultado.
• Freqüência da ocorrência.
• Inúmeras são as maneiras em que o problema pode ser resolvido.
• Algumas ações são difíceis ou impossíveis de recuperação.
• Os usuários não podem compreender porque uma ação poderia ser
prejudicial.
• Os usuários não podem compreender as conseqüências ou as opções.
• Se ocorrer um problema dependendo da qualidade isto é muito ruim
para ele?

SOLUÇÕES: Advirta o usuário antes de continuar a tarefa e dê á ele a

possibilidade de abortar as tarefas.

O aviso deve conter os seguintes elementos:

• Um sumário do problema.
• A Condição que provocou o aviso.
• Uma pergunta que questiona aos usuários se continua a ação ou
toma outras ações.

- 14 -
 • Duas escolhas principais para que o usuário possa fazer a escolha
uma afirmativa e outra em que é abortado.

O Aviso pôde também incluir uma descrição mais detalhada da situação

para ajudar ao usuário fazer a decisão apropriada. As escolhas devem ser
indicadas com um verbo que consulte à ação requerida. Não use Yes/No
como escolhas. As escolhas são respostas à pergunta que é feita.

Em alguns casos pode haver mais de duas escolhas. Aumentar o

número das escolhas pode ser aceitável em alguns casos mas tente
minimizá-las.

RAZÃO: Indicando a circunstância que o usuário provocou pode

compreender porque o aviso aparece. Uma vez que isso é compreendido
a pergunta deixa o usuário somente com duas opções. Fornecendo
somente duas opções para o usuário, á escolha feita é simples: continue
ou aborte. Mais opções fazem a decisão do usuário mais difícil.
Usando um verbo nas opções, o usuário saberá imediatamente que á
escolha do Yes/No requer que o usuário recorde exatamente de como era
á pergunta. A solução diminui erros e aumenta a satisfação.

EXEMPLO:

Este screenshot vem de Eudora 4, e se você tentar sair do o

programa ele mostra que mesmo três escolhas podem ser aceitáveis.

EXEMPLOS CONHECIDOS: Eudora, Installshield installers (Quando Sair)

PADRÕES RELACIONADOS: Proteção

- 15 -
 HINTING

PROBLEMA: O usuário necessita saber selecionar funções

PRINCÍPIO DA USABILIDADE: Revelar o incremento (Visibilidade)

CONTEXTO: Aplicações onde á funcionalidade é acessível em mais do que

uma opção, por exemplo através dos menus, usando atalhos do teclado,
ou através das barras de ferramentas. Este teste padrão pode ser usado
para fazer o usuário ficar ciente das outras possibilidades em uma
maneira sutil e de um modo não obstrutivo.

SITUÇÕES:

• O espaço de tela disponível pode ser limitado, assim não há nenhum

espaço para sugestões visuais extras.
• O usuário precisa de algum modo para descobrir e aprender estas
alternativas e possivelmente modos mais eficientes e não obstrutivo.
• O usuário pode ou não saber os outros modos para ter acesso a
função.
• O número de modos para ativar a função determina o número de
possíveis sugestões.
SOLUÇÕES: Dê as sugestões ao usuário de outros modos para ter acesso
á mesma função.
Ao ter acesso á uma função através de um modo, preveja sugestões
para outros modos para ter acesso á mesma função.
Uma possibilidade é usar rótulos múltiplos; Um rótulo para cada função
pode ser um modo tido como acesso. Por exemplo, se a função tiver um
atalho de teclado, mostre a combinação fundamental. Se há um atalho de
ícone para a função, mostre o ícone. Sempre mostre o rótulo principal e se
possível outros rótulos diretamente dentro das constrainst.
Outras possibilidades são usar agentes de ajuda ou mensagens
atrasadas que reagem as ações dos usuários. Por exemplo, um display é

- 16 -
exibido quando o usuário segurar o mouse em cima de um objeto por
aproximadamente dois segundos.

RAZÃO: São altas as chances de o usuário estar familiarizado com pelo

menos um modo de acesso á uma função específica. Mostrando outros
modos como atalhos fundamentais ou ícones, incentivará o usuário a
aprender mais. Em algum ponto o usuário poderá ver o ícone melhor na
barra de ferramentas do que no menu. Da mesma maneira, o usuário
pode preferir fazer o acesso através do teclado do que pelo mouse. A
solução aumenta a leitura e a memorização. A partir do momento em que
o usuário passa a usar outros modo de acesso a velocidade do
desempenho também pode aumentar.

EXEMPLO:

Este screenshots são vem do Word2000. Os exemplos são uma

ferramenta e ou menu usando ícones.

EXEMPLOS CONHECIDOS: Barra de Ferramenta e menus do Office

2000.

PADRÕES RELACIONADOS: Área de comando

- 17 -
 MODE CURSOR

PROBLEMA: O usuário está criando ou está modificando um objeto e

precisa saber qual função está selecionada.

PRINCÍPIO DA USABILIDADE: Retorno imediato (Retorno).

CONTEXTO: Em muitas aplicações de manipulação diretas os usuários

primeiro selecionam uma ferramenta/função , assim entrando em especial
num mode/propriedade, e então trabalham em um objeto. Como certas
aplicações normalmente oferecem muitas funções para criar ou modificar
objetos.

SITUÇÕES:

• Nem toda função pode ter um ícone ou forma.

• Ao completar uma função podem causar vários estados
intermediários para os quais também podem precisar que sejam
mostrados.
• O usuário precisa de avaliação imediata para a função selecionada,
isto é qual o modo no sistema.

SOLUÇÕES: Mostrar ao usuário o estado de interface do cursor.

Muitas vezes durante á interação ocorre mudanças na interface, por

exemplo, quando uma função é selecionada ou quando uma ação como
arrastar é executada. Então, mostre ao usuário mudando o cursor. O
cursor pode ser mudado á um ícone ou alguns, outra forma que dá
avaliação sobre o estado de interface atual. Mude o cursor atrás para um
cursor neutro se a função é completada ou é desativada.

RAZÃO: O cursor dá avaliação extra sobre a função ativa. O usuário

assiste o cursor ao executar uma função, assim é o lugar mais apropriado
na tela dar avaliação isto é, o usuário não precisa olhar para outro canto
da tela. A solução é a satisfação do usuário e pode diminuir erros

- 18 -
EXEMPLO:

Este screenshot é do Adobe Photoshop 5. O usuário selecionou a função

como indicado no painel de função esquerdo. O cursor mudou e agora
teve a mesma forma como o ícone de função.

EXEMPLOS CONHECIDOS: Photoshop, Illustrator, Powerpoint

- 19 -
 LIST BROWSER

PROBLEMA: O usuário que precisa folhear ou processar vários artigos

fora de uma lista.

PRINCÍPIO DA USABILIDADE: Minimizar as ações (Mapeando

Naturalmente).

CONTEXTO: Em muitas aplicações o usuário precisa passar por uma lista

de artigos. Por exemplo, quando está lendo notícias em um website ou ao
olhar os resultados de um banco de dados em questão. O usuário
seleciona um artigo inicial fora de uma lista e então quer mover para
outros artigos. Em geral, o usuário quer ler vários artigos da lista na
ordem ou de trás para frente.

SITUAÇÕES:
• O usuário quer ver uma avaliação da lista e também um artigo, mas

a tela ou o espaço pode não ser suficiente para mostrar ambos.

• O usuário precisa poder selecionar um artigo individual como
também processar vários artigos.

SOLUÇÕES: Achar uma ordenação natural e que permite ao usuário

navegar diretamente de um artigo para outro. Baseado em conhecimento
da tarefa, imponha uma ordenação na lista. A ordenação pode ser
baseado em uma posição, por exemplo relevância, em valores de campo
de exemplo data/tempo ou uma projeção de uma estrutura existente por
exemplo flattening/traversing uma árvore. Até mesmo uma ordenação
arbitrária é útil. Para todo artigo que é apresentado ao usuário, um widget
de navegação permite para o usuário escolher o próximo ou prévio artigo
na lista. O critério de ordenação deveria ser visível (se deveria ser
configurado pelo usuário). Apoiar orientação, o artigo atual e uma lista de
índice parcial devem seja claramente visível. Se aumentou complexidade
não é considerada um problema, o artigo atual, indicador de número

- 20 -
poderia ser um diálogo que apóia saltando a artigos arbitrários, diálogo,
elementos por saltar ao topo e fundo poderia ser somado, como também
um elemento para trocando a uma visão de list/index/TOC cheia.

RAZÃO: Dando para o usuário um modelo de navegação simples e

permitindo para o usuário ir diretamente para o próximo artigo , o usuário
não precisa voltar para o índice para selecionar o próximo artigo. A
solução melhora a velocidade de desempenho e satisfação.

EXEMPLO:

Exemplos são websites de notícias ou o espectador de evento. Uma

notícia é mostrada e então você possa ir para o próximo. Deste modo o

- 21 -
usuário não precisa voltar para o índice. Preferivelmente o índice também
está lá, pelo menos parcialmente (mostrando o contexto do artigo atual).

EXEMPLOS CONHECIDOS: Atlas F1 News Website, NT4 Event viewer

PADRÕES RELACIONADOS: Wizard, navegando entre espaços.

- 22 -
 CONTINUOUS FILTER

PROBLEMA: O usuário que precisa achar um artigo em uma lista

ordenada.

PRINCÍPIO DA USABILIDADE: Retorno Imediato (Retorno).

CONTEXTO: Este padrão permite o usuário a dinamicidade e estreita a

procura que depende de uma avaliação imediata dada pelo filtro contínuo.

SITUAÇÕES:

• O usuário está procurando um artigo em uma grande lista ordenada

e pode não estar familiarizado como artigo exato, nem é certo ao
usuário que o artigo existe.
• O usuário procura um artigo, mas o termo de procura pode conduzir
a múltiplos resultados.

SOLUÇÕES: Providenciar um componente de filtro com que o usuário

pode em tempo real ver só os artigos dentre dos dados que são do
interesse dele. O filtro é mostrado concorrentemente com o termo de
procura do momento em que o usuário entrou no termo de procura. Se
pertinente, as partidas mais íntimas são realçadas enquanto alguns
previamente e poderiam ser mostrados artigos sucessivos como bem.

RAZÃO: Porque o usuário adquire á avaliação imediata no termo de

procura, o usuário procura mesmo eficazmente e pode até mesmo ver
outros artigos pertinentes. Porque os artigos filtrados são mostrados e o
usuário pode ajustar o termo de procura em tempo real ou até mesmo um
atalho que completa o termo de procura e vai diretamente para o artigo
preferido. A solução melhora o tempo de desempenho e satisfação.

- 23 -
EXEMPLOS:

Este screenshot e do Cakewalk 9 a funcionalidade de ajuda comum. No

índice funcione o usuário é com guia para o artigo enquanto digitando.

Este screenshot mostra a história de URL de Internet Explorer 5.

Como você digite um URL isto espetáculos a lista de possíveis URLs que
emparelham o URL inacabado.

- 24 -
EXEMPLOS CONHECIDOS: Sistemas de Ajuda de Usos conhecidos
(Cakewalk, MS Palavra 2000, Estúdio 6 Visual), Internet Explorer 5,
IntelliSense).
PADRÕES RELACIONADOS: Favoritos.

PADRÕES DE ESTADOS RELACIONADOS

Os padrões foram desenvolvidos principalmente examinando

aplicações freqüentemente usadas e indo por diretrizes.
A maioria de nossos esforços concentrou em escrever abaixo os
padrões com um foco consistente como descrito nas seções prévias.
Os padrões apresentados aqui são parte de um esforço colaborador
contínuo; padrões foram distribuídos através de e-mail e discutiram por
um grupo de três pessoas.
Ultimamente, nós começamos usando um BSCW workspace
colaborador para ser anfitrião do seminário de uns escritores virtuais por
validar e melhorar os padrões.
Nós esperamos que nosso trabalho sensibilize outras forma ques nós
pode trabalhar junto no desenvolvimento de um verdadeiro padrão
idioma.

RECONHECIMENTOS

Graças a David Kane e de Nicolò Faveri Tron por discutir alguns destes
padrões conosco. Também muitos graças a Jutta Eckstein nosso guru que
deu uns muitos comentários de insightful.

REFERÊNCIAS

Bayle, E. (1998), Putting it All Together: Towards a Pattern Language for

Interaction Design, SIGCHI Bulletin, vol 30, no. 1, pp.17-24.

Hartson, H.R. (1998), Human-computer interaction: Interdisciplinary roots

and trends, The Journal of Systemsand Software, vol 43, pp.103-118.

- 25 -
Mahemoff, M. J. and Johnston, L. J. (1998), Pattern Languages for
Usability: An Investigation of Alternative Approaches, Asia-Pacific
Conference on Human Computer Interaction (APCHI) 98.

McKay, E. N. (1999), Developing User Interfaces for Microsoft Windows,

Microsoft Press,

Norman, D. (1988), The Design of Everyday Things, Basic Books,

Perzel, K. and Kane, D. (1999), Usability Patterns for Applications on the

World Wide Web, PloP '99.

Rijken, D. (1994), The Timeless Way .. the design of meaning, SIGCHI

Bulletin, vol 6, no. 3, pp.70-79.

Tidwell, J. (1998), Interaction Design Patterns, PloP '98.

van Welie, M., van der Veer, G. C., and Eliëns, A. (1999), Breaking down
Usability, Proceedings of Interact '99, Edinburgh, Scotland.

- 26 -