Universidade de BrasliaInstituto de Cincias Exatas

Departamento de Cincia da Computao

Mtodo de Avaliao de Comunicabilidade daEngenharia Semitica: um estudo de caso em um

sistema Web

Arthur Thiago Barbosa Nobrega

Herlanio Leite Gonalves

Monograa apresentada como requisito parcial

para concluso do Bacharelado em Cincia da Computao

Orientadora

Prof.a Dr.a Fernanda Lima

Braslia

2013

Universidade de Braslia UnB

Instituto de Cincias Exatas

Departamento de Cincia da Computao

Bacharelado em Cincia da Computao

Coordenador: Prof. Dr. Alexandre Zaghetto

Banca examinadora composta por:

Prof.a Dr.a Fernanda Lima (Orientadora) CIC/UnB

Prof. Dr. Homero Luiz Piccolo CIC/UnB

Prof.a Dr.a Maria de Ftima Ramos Brando CIC/UnB

Prof.a Me. Layany Zambrano Horta Damzio CIC/UnB

CIP Catalogao Internacional na Publicao

Nobrega, Arthur Thiago Barbosa.

Mtodo de Avaliao de Comunicabilidade da Engenharia Semitica:

um estudo de caso em um sistema Web / Arthur Thiago Barbosa No-

brega, Herlanio Leite Gonalves. Braslia : UnB, 2013.

201 p. : il. ; 29,5 cm.

Monograa (Graduao) Universidade de Braslia, Braslia, 2013.

1. Interao Humano-Computador, 2. Engenharia Semitica,

3. Avaliao

CDU 004.5

Endereo: Universidade de Braslia

Campus Universitrio Darcy Ribeiro Asa Norte

CEP 70910-900

BrasliaDF Brasil

Universidade de BrasliaInstituto de Cincias Exatas

Departamento de Cincia da Computao

Mtodo de Avaliao de Comunicabilidade daEngenharia Semitica: um estudo de caso em um

sistema Web

Arthur Thiago Barbosa Nobrega

Herlanio Leite Gonalves

Monograa apresentada como requisito parcial

para concluso do Bacharelado em Cincia da Computao

Prof.a Dr.a Fernanda Lima (Orientadora)

CIC/UnB

Prof. Dr. Homero Luiz Piccolo Prof.a Dr.a Maria de Ftima Ramos Brando

CIC/UnB CIC/UnB

Prof.a Me. Layany Zambrano Horta Damzio

CIC/UnB

Prof. Dr. Alexandre Zaghetto

Coordenador do Bacharelado em Cincia da Computao

Braslia, 25 de fevereiro de 2013

Resumo

O nmero de sistemas na Web aumenta a cada dia, e, junto, cresce a importn-cia de avaliar a experincia do usurio com esses sistemas. Avaliaes podem ser feitasantes, durante e depois do desenvolvimento e existem diferentes formas de avaliar, comopor exemplo: a vericao do cumprimento dos objetivos propostos na sua concepo,seguindo a rea de Engenharia de Software (ES), ou a avaliao da interao do usuriocom a interface do sistema, seguindo a rea de Interao Humano-Computador (IHC).Alm disso, as avaliaes podem ou no contar com a participao de possveis usurios.O desao deste trabalho avaliar um estudo de caso que no teve a preocupao, duranteo processo de desenvolvimento, de testar o sistema com possveis usurios. Utilizou-se aviso da Engenharia Semitica, que uma teoria da IHC, fazendo-se uso do Mtodo deAvaliao de Comunicabilidade (MAC), que entende um sistema computacional como umametamensagem que passada do designer para o usurio. Este mtodo identica falhasexistentes na comunicao entre o que foi planejado e o que foi realmente percebido pelosparticipantes durante as sesses de avaliao. A principal contribuio deste trabalho foio conjunto de documentos gerados que podem ser utilizados como uma base para guiarnovos avaliadores na conduo de sesses de avaliao fazendo-se uso da tcnica Thinkaloud . Alm disso, outra importante contribuio foi a constatao de que problemas deacessibilidade excluem possveis usurios de utilizarem o sistema.

A viso da Engenharia Semitica, que uma teoria de IHC, foi o foco deste trabalho.Esta teoria enxerga um sistema computacional como uma meta-mensagem passada dodesigner para o usurio. O Mtodo de Avaliao de Comunicabilidade (MAC), que usa aviso da Engenharia Semitica, foi utilizado para fazer as avaliaes com os usurios. Estemtodo identica falhas na comunicao entre o que foi planejado e o que foi realmentepercebido pelos participantes durante as sesses de avaliao. A principal contribuiodeste trabalho foi o conjunto de documentos gerados que podem ser utilizados comobase para guiar novos avaliadores na realizao de sesses de avaliao que fazem uso datcnica Think aloud . Alm disso, outra contribuio importante foi a percepo de queproblemas de acessibilidade excluem potenciais usurios de utilizar o sistema.

Palavras-chave: Interao Humano-Computador, Engenharia Semitica, Avaliao

i

Abstract

The number of systems on the Web increases every day, and with it grows the impor-tance to evaluate the user experience on these systems. Assessments can be made before,during and after development and can be made in dierent ways, for example: vericationof compliance with the proposed objectives in its design, supporting the area of SoftwareEngineering (SE), or the evaluation of the user interaction with the system`s interface,following the area of Human-Computer Interaction (HCI). Moreover, the evaluations mayor may not count with the participation of potential users. The challenge of this researchis to evaluate a case study that had no concern testing the system with potential usersduring the process of development. The vision of Semiotic Engineering, which is a theoryof IHC, was the focus of this work. This theory sees a computer system as a meta messagethat is passed from designer to user. The Communicability Evaluation Method (CEM),that use the vision of the Semiotic Engineering, was used to make the evaluations withthe users. This method identies gaps in communication between what was planned andwhat was actually perceived by participants during the evaluation sessions. The main con-tribution of this work was the set of documents generated that can be used as a guide fornew evaluators in conducting evaluation sessions that uses the technique Think aloud.Moreover, another important contribution was the realization that accessibility problemsexclude potential users from using the system.

Keywords: Human-Computer Interaction, Semiotic Engeneering, Evaluation

ii

Sumrio

1 Introduo 11.1 Contextualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3.2 Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Organizao da Monograa . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Referencial Terico 42.1 Conceitos Bsicos de Interao Humano-Computador . . . . . . . . . . . . 4

2.1.1 Termos relevantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Estilos de interao . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Avaliao de Interao Humano-Computador em aplicaes Web . . . . . . 92.2.1 Mtodos de avaliao . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Comparativo dos mtodos de avaliao . . . . . . . . . . . . . . . . 132.2.3 Planejamento da avaliao de IHC . . . . . . . . . . . . . . . . . . 152.2.4 Framework DECIDE . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5 Engenharia Semitica . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.6 Mtodo de Avaliao de Comunicabilidade . . . . . . . . . . . . . . 24

2.3 Acessibilidade Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.1 Recomendaes de acessibilidade do Consrcio W3C . . . . . . . . 272.3.2 Acessibilidade segundo o programa de governo eletrnico brasileiro . 32

3 Contexto de Aplicao do MAC 333.1 Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.1 Anlise de possveis estudos de caso . . . . . . . . . . . . . . . . . . 333.1.2 Estudo de caso escolhido . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Etapas do framework DECIDE neste estudo de caso . . . . . . . . . . . . . 383.2.1 Determinar as metas da avaliao . . . . . . . . . . . . . . . . . . . 383.2.2 Explorar as questes para alcanar os objetivos . . . . . . . . . . . 383.2.3 Escolher o paradigma da avaliao e as tcnicas de respostas . . . . 383.2.4 Identicar questes prticas que devem ser resolvidas antes das ava-

liaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.5 Decidir como abordar aspectos ticos . . . . . . . . . . . . . . . . . 393.2.6 Avaliar, interpretar e apresentar os resultados . . . . . . . . . . . . 39

iii

3.3 Etapas do Mtodo de Avaliao de Comunicabilidade . . . . . . . . . . . . 403.3.1 Preparao do teste . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.2 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3.3 Interpretao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3.4 Consolidao e relato dos resultados . . . . . . . . . . . . . . . . . . 47

3.4 Coleta de problemas de acessibilidade do sistema . . . . . . . . . . . . . . 47

4 Anlise dos Resultados 504.1 Consolidao dos dados e relato dos resultados . . . . . . . . . . . . . . . . 50

4.1.1 Problemas de comunicabilidade encontrados . . . . . . . . . . . . . 504.1.2 Causa dos problemas mais recorrentes . . . . . . . . . . . . . . . . 544.1.3 Perl Semitico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.1.4 Anlise do questionrio ps-teste . . . . . . . . . . . . . . . . . . . 57

4.2 Possveis solues para os problemas encontrados . . . . . . . . . . . . . . 584.2.1 Comparao da verso original com a verso modicada . . . . . . 584.2.2 Avaliaes da verso modicada . . . . . . . . . . . . . . . . . . . . 74

4.3 Avaliao de acessibilidade com usurio real . . . . . . . . . . . . . . . . . 76

5 Consideraes nais 775.1 Anlise crtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Principais contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Referncias 79

A Roteiro da Avaliao 81

B Termo de Consentimento 82

C Questionrio Demogrco 83

D Informaes ao Participante 85

E Tarefas 86

F Ficha do Observador 87

G Questionrio Ps-Teste 88

H Dados Demogrcos 89

I Avaliao Ps-Teste dos Participantes 92

iv

Lista de Figuras

2.1 interao entre usurio e sistema. Fonte: Prates e Barbosa (2007). . . . . 52.2 exemplo de linguagem de comando - Terminal do Linux. . . . . . . . . . . 82.3 exemplo de interface WIMP. Fonte: adaptado de de Souza et al. (1999). . . 92.4 exemplo de prottipo em papel. Fonte: Barbosa e Silva (2010). . . . . . . . 112.5 atividades de uma avaliao heurstica. Fonte: Barbosa e Silva (2010) . . . 122.6 aspectos geralmente avaliados por meio de cada mtodo. Fonte: Barbosa

e Silva (2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 quando cada mtodo de avaliao costuma ser utilizado. Fonte: Barbosa e

Silva (2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 tipos de dados produzidos por cada mtodo de avaliao. Fonte: Barbosa

e Silva (2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.9 exemplo de laboratrio para observar um participante utilizando um sis-

tema computacional interativo. Fonte: Barbosa e Silva (2010). . . . . . . . 172.10 denio de signo segundo Peirce. Fonte: Peirce (1998) (modicado). . . . 212.11 semiose ilimitada. Fonte: Prates e Barbosa (2007). . . . . . . . . . . . . . 222.12 signos tradicionais do Windows. . . . . . . . . . . . . . . . . . . . . . . . . 222.13 processo da comunicao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.14 atividades do Mtodo de Avaliao de Comunicabilidade. Fonte: Barbosa

e Silva (2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.15 componentes para o desenvolvimento de aplicaes acessveis. Fonte: http:

//www.w3.org/WAI/intro/components.php . . . . . . . . . . . . . . . . . 302.16 ciclo explicitando a interdependncia entre os componentes. Fonte: Henry

(2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.17 grco mostrando a diculdade na implementao da acessibilidade quando

um dos componentes no a implementa. Fonte: Henry (2005) . . . . . . . . 31

3.1 tela inicial do estudo de caso escolhido. . . . . . . . . . . . . . . . . . . . . 363.2 formas de resolver simulados no sistema: por disciplina ou por provas com-

pletas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36(a) simulados de questes por disciplina . . . . . . . . . . . . . . . . . . 36(b) simulados de provas completas . . . . . . . . . . . . . . . . . . . . . 36

3.3 tela de resoluo de simulados. . . . . . . . . . . . . . . . . . . . . . . . . . 373.4 porcentagem de uso dos navegadores no mundo em perodo de dois anos.

Fonte: StatCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 comparao dos campos obrigatrios na verso original e na verso modicada 58(a) verso original do sistema . . . . . . . . . . . . . . . . . . . . . . . 58

v

http://www.w3.org/WAI/intro/components.phphttp://www.w3.org/WAI/intro/components.php

(b) verso modicada do sistema . . . . . . . . . . . . . . . . . . . . . 584.2 comparao do campo de texto ao lado do elemento de ajuda com um

campo select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58(a) verso original do sistema . . . . . . . . . . . . . . . . . . . . . . . 58(b) verso modicada do sistema . . . . . . . . . . . . . . . . . . . . . 58

4.3 comparao de campo de texto com elemento de ajuda na verso originale na verso modicada do sistema . . . . . . . . . . . . . . . . . . . . . . . 60(a) verso original do sistema . . . . . . . . . . . . . . . . . . . . . . . 60(b) verso modicada do sistema . . . . . . . . . . . . . . . . . . . . . 60

4.4 comparao de campo de texto com elemento de ajuda na verso originale na verso modicada do sistema . . . . . . . . . . . . . . . . . . . . . . . 60(a) verso original do sistema . . . . . . . . . . . . . . . . . . . . . . . 60(b) verso modicada do sistema . . . . . . . . . . . . . . . . . . . . . 60

4.5 tela dos grcos de Assuntos mais Frequentes na verso original do sis-tema sem ligao com a tela de resoluo . . . . . . . . . . . . . . . . . . . 61

4.6 tela dos grcos de Assuntos mais Frequentes na verso modicada, fa-zendo a ligao com a tela de resoluo do assunto escolhido . . . . . . . . 62

4.7 janela com pergunta se o usurio deseja fazer questes do assunto selecio-nado no grco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.8 breadcrumbs na verso original do sistema . . . . . . . . . . . . . . . . . . 634.9 Meu painel na verso original do sistema, sem um link para voltar

pgina inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.10 nova verso do Meu painel, com o link para voltar pgina inicial . . . . 644.11 verso modicada do texto de ajuda nas opes da tela de resoluo . . . . 644.12 nova verso da caixa de mensagem para aes do usurio . . . . . . . . . . 654.13 nova verso da forma de se mostrar a Resposta automtica . . . . . . . . 65

(a) opo Resposta automtica desabilitada . . . . . . . . . . . . . . 65(b) opo Resposta automtica habilitada . . . . . . . . . . . . . . . 65

4.14 nova verso da forma de se mostrar o texto . . . . . . . . . . . . . . . . . . 66(a) verso modicada do boto Mostrar texto, substituindo o texto . 66(b) verso modicada do boto lateral que segue a tela do usurio para

mostrar o texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.15 texto da questo na verso original do sistema . . . . . . . . . . . . . . . . 674.16 nova verso da nova forma de se mostrar o texto (texto escondido) . . . . . 684.17 nova verso da forma de se mostrar o texto (texto sendo exposto) . . . . . 694.18 botes que aparecem abaixo da questo na verso original do sistema . . . 704.19 verso modicada dos botes que aparecem abaixo da questo . . . . . . . 704.20 funcionalidade Marcadores na verso original do sistema . . . . . . . . . 704.21 verso modicada da forma de se gerenciar os marcadores das questes . . 714.22 informaes da questo localizadas junto com dados do simulado na verso

original do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.23 verso modicada das informaes da questo . . . . . . . . . . . . . . . . 724.24 nova verso da forma de se controlar a contagem do tempo . . . . . . . . . 72

(a) controle de contagem de tempo na verso original do sistema . . . . 72(b) verso modicada do controle de contagem de tempo . . . . . . . . 72

vi

4.25 nova verso da janela que aparece na primeira vez que o usurio acessa atela de resoluo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.26 exemplo de caixa de informao que aparece quando o usurio escolhe fazero tour na verso modicada . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.27 opes de atalho que o usurio pode escolher aps selecionar a opo Ata-lhos na barra lateral da verso modicada . . . . . . . . . . . . . . . . . . 74

vii

Lista de Tabelas

3.1 comparao entre os principais sistemas de estudo para concursos pblicoscitados pelos participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 etapas do Mtodo de Avaliao de Comunicabilidade. Fonte: Barbosa eSilva (2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 comparao dos quatro navegadores mais utilizados no mundo no uso dosistema da Rota dos Concursos . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 problemas de comunicabilidade encontrados em cada uma das tarefas dosparticipantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5 problemas de acessibilidade segundo o WCAG 2.0 encontrados na pginainicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6 problemas de acessibilidade segundo o WCAG 2.0 encontrados na tela deltro dos assuntos mais frequentes . . . . . . . . . . . . . . . . . . . . . . . 48

3.7 problemas de acessibilidade segundo o WCAG 2.0 encontrados nas questespor disciplina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.8 problemas de acessibilidade segundo o WCAG 2.0 encontrados na tela deresoluo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 classicao de etiquetas em relao ao tipo de falhas. Fonte: Prates eBarbosa (2007) (modicado) . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 nmero de ocorrncias de problemas por etiqueta . . . . . . . . . . . . . . 524.3 nmero de participantes que apresentou cada etiqueta . . . . . . . . . . . . 534.4 problemas mais recorrentes e respectiva soluo desenvolvida na verso

modicada do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5 dados coletados nas sesses de avaliao da nova verso . . . . . . . . . . . 75

H.1 dados pessoais e formao dos participantes . . . . . . . . . . . . . . . . . 89H.2 experincia em estudo online e na rea de concursos pblicos . . . . . . . . 90H.3 experincia e uso dirio de Desktops/Notebooks, Tablets e Smartphones . . 90H.4 habilidade e conforto percebidos pelos participantes paraDesktops/Notebooks,

Tablets e Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

I.1 feedback dos usurios sobre a experincia para os quesitos: facilidade deaprendizado, segurana no uso e efetividade no uso. . . . . . . . . . . . . . 92

I.2 feedback dos usurios sobre a experincia para os quesitos: esteticamenteaprecivel, desaador e til. . . . . . . . . . . . . . . . . . . . . . . . . . . 93

viii

Captulo 1

Introduo

1.1 Contextualizao

AWeb ganha, a cada dia, mais importncia no cenrio mundial e vem se estabelecendocomo um dos principais meios de comunicao da nossa sociedade. Segundo o InternetWorld Stats 1, em dezembro de 2011, 32,7% da populao mundial possuam acesso Internet, um crescimento de 528,1% desde 2000. Estudiosos armam que a Internetcontinuar a crescer medida que mais pessoas tiverem acesso uma renda maior, poisdessa forma podero comprar diferentes tipos de dispositivos tecnolgicos, e tambm medida que mais reas tiverem acesso grande rede.

Alm disso, com a diversidade de dispositivos, surge a necessidade de serem desenvol-vidos sistemas Web que possam ser acessveis em tablets, celulares, notebooks, etc. Porm,para que estes sistemas sejam realmente portveis, necessrio que sigam um padro de-nido internacionalmente, em que vrios dispositivos possam processar os dados e mostrarao usurio a informao desejada sem que haja problemas de interpretao.

O Consrcio World Wide Web (W3C) 2 responsvel por denir recomendaes paraque a rede mundial de computadores seja um espao democrtico e plural, onde as pes-soas, independentemente de dispositivo, sistema operacional ou at mesmo localizaogeogrca, possam visualizar o contedo de forma acessvel. O grande esforo do W3C estimular os desenvolvedores de Stios da Web a seguirem essas recomendaes, pois,ainda hoje, uma grande parte no se atenta a esses padres.

Ainda na rea de qualidade de um sistema Web, preciso avaliar se a proposta que odesenvolvedor construiu realmente est cumprindo o papel para o qual foi pensado. Paraisso existem padres de desenvolvimento em Engenharia de Software que ajudam a equipede especialistas a se organizarem, por exemplo, criando uma especicao de requisitos evalidando-a durante e aps a fase de desenvolvimento. Outra forma de validar a qualidadedeste software da perspectiva da Interao Humano-Computador (IHC), que valida osistema com a viso do usurio, entendendo quais prticas so mais interessantes paraatingir uma melhor usabilidade e experincia para o usurio e no apenas se o sistematem a funcionalidade que foi planejada.

Dentro da IHC h a rea de pesquisa da Engenharia Semitica, que, segundo de Souza(2005), entende a IHC como:

1http://www.Internetworldstats.com/stats.htm2http://www.w3.org

1

http:// www.Internetworldstats.com/stats.htm

...uma comunicao entre designers e usurios em tempo de interao mediada porum computador. O sistema fala por seus designers em diversos tipos de conversasplanejadas antes do desenvolvimento. Estas conversas comunicam o entendimentodos designers sobre quem so os usurios, o que os usurios querem ou precisam fa-zer, quais so as formas preferidas de executar essas aes e porque. As mensagensdos designers para os usurios tambm incluem a linguagem interativa pela qual osusurios se comunicaro de volta com o sistema, a m de atingir seus objetivos espe-ccos. Ento, o processo , na verdade, uma comunicao sobre uma comunicao,ou seja, uma metacomunicao.

Ainda segundo a Engenharia Semitica existem dois mtodos de avaliao nesta teoria:o Mtodo de Avaliao de Comunicabilidade (MAC) e o Mtodo de Inspeo Semitica(MIS), que so ambos mtodos qualitativos. O MAC faz uso de avaliaes presenciais comusurios com o objetivo de identicar os problemas na comunicabilidade da aplicao. Jo MIS se utiliza de especialistas para avaliar a comunicabilidade do sistema, sem interaocom usurios reais. Neste trabalho ser avaliado um sistema com base no MAC.

1.2 Problema

Esse trabalho pretende responder a seguinte pergunta: Em um sistema que no fezuso de um mtodo cientco durante o seu desenvolvimento, possvel utilizar o Mtodode Avaliao de Comunicabilidade para identicar problemas de comunicabilidade?

1.3 Objetivo

Esta seo descreve o objetivo geral e os objetivos especcos deste trabalho.

1.3.1 Objetivo geral

O objetivo do trabalho realizar avaliaes em um sistema real, que no fez uso deum mtodo cientco durante o seu desenvolvimento, para identicar falhas de comunica-bilidade, utilizando o Mtodo de Avaliao de Comunicabilidade (MAC) da EngenhariaSemitica.

1.3.2 Objetivos especcos

Os objetivos especcos deste trabalho so:

elaborar resumo com viso geral de onde se encaixa o MAC;

estruturar e realizar coleta de dados que permita avaliaes de sistemas Web comusurios reais;

analisar os dados coletados e documentar conceitualmente os aspectos da propostade soluo dos problemas encontrados;

modicar o sistema Web avaliado no estudo de caso para ser utilizado em novarodada de avaliao com usurios;

2

buscar novas etiquetas de problema de comunicabilidade para contribuir com aevoluo do MAC;

redigir textos acadmicos para apresentao em eventos cientcos relacionados aotema desse trabalho, de modo a buscar avaliao das comunidades de IHC e Web,envolvidas em questes atuais abordadas nas referidas comunidades em mbito na-cional e internacional.

1.4 Metodologia

Esta seo descreve a metodologia utilizada na realizao deste trabalho.A primeira atividade realizada foi a pesquisa bibliogrca, a m de que os autores se

familiarizassem com o tema geral. Segundo Cervo et al. (2007), esta atividade de grandeimportncia para embasar o desenvolvimento da monograa em uma fundamentao te-rica.

A pesquisa realizada neste trabalho pode ser considerada experimental. Foram pes-quisadas questes relacionadas ao Mtodo de Avaliao de Comunicabilidade (MAC) daEngenharia Semitica, avaliaes com usurios, teorias da IHC e as principais recomen-daes para acessibilidade na Web.

Na fase seguinte, foram selecionados usurios reais para participarem de sesses deavaliao seguindo o MAC, com o objetivo de coletar dados sobre as falhas de comuni-cabilidade existentes no estudo de caso. Com os dados destas pesquisas, foi desenvolvidauma verso modicada que buscou minimizar as falhas encontradas.

1.5 Organizao da Monograa

O restante desta monograa est organizada da seguite forma:No captulo 2, so expostas as bases tericas nas quais esse trabalho se sustenta, pre-

parando o leitor para que assim possa compreender o contexto no qual esta monograa seinsere. So citadas diversas fontes de reas inovadoras, tais como a Engenharia Semiticae mais especicamente o Mtodo de Avaliao de Comunicabilidade.

No captulo 3, se encontra a contexto de aplicao do MAC para o problema explicitadoacima. So expostos os documentos utilizados no decorrer da implementao, bem comoos passos para atingir o objetivo proposto.

No captulo 4, so analisados os dados coletados durante a implementao do projetode pesquisa e avaliados cada um dos artefatos gerados.

Por m, no captulo 5, so feitas as consideraes nais, por meio de: uma anlisecrtica desse trabalho, um roteiro das principais contribuies e uma lista de possveistrabalhos futuros.

3

Captulo 2

Referencial Terico

2.1 Conceitos Bsicos de Interao Humano-Computador

Existem diferentes formas de lidar com avaliaes de sistemas que envolva a interaode pessoas com dispositivos computacionais. Podem-se destacar duas abordagens: a deEngenharia de Software (ES) e a de Interao Humano-Computador (IHC).

Tradicionalmente, a ES divide a avaliao em vericao, validao e teste. SegundoSommerville (2007), na vericao avalia-se se o software est seguindo as especicaesdocumentadas atravs de requisitos. Na validao analisado se o sistema atende snecessidades do cliente. No teste realizam-se avaliaes diretamente no cdigo executvel.

J a IHC tem um foco mais acentuado na experincia de interao entre o usurio e osistema, por meio da interface. Como esse trabalho se enquadra dentro da rea de IHC,nas prximas sees sero explorados conceitos desta rea que foram usados como basepara essa monograa.

2.1.1 Termos relevantes

Nas ltimas dcadas, o design de interface tem ganhado cada vez mais importncia,segundo de Souza et al. (1999). Interface, de acordo com Moran (1981), a parte deum sistema computacional com a qual a pessoa entra em contato fsica, perceptivaou conceitualmente, como podemos visualizar na Figura 2.1. Nesta denio, Morancaracteriza a interface como possuindo uma parte fsica, que o usurio percebe e manipula,e uma parte conceitual, que o usurio interpreta, processa e raciocina.

A interface, segundo de Souza et al. (1999), possui componentes de hardware e de soft-ware. Os componentes de hardware so, por exemplo, teclado, mouse, monitor, cmera,dentre outros. Os componentes de software so aqueles que: (a) controlam os componen-tes de hardware; (b) constroem os dispositivos virtuais com os quais o usurio interage;(c) geram diversos smbolos e mensagens que representam as informaes do sistema e (d)interpretam os comandos do usurio.

4

Figura 2.1: interao entre usurio e sistema. Fonte: Prates e Barbosa (2007).

por meio da interface que o usurio gera aes e recebe as respostas do sistema,que ele interpreta para gerar novas aes. A essa comunicao d-se o nome de interao[Preece et al. (1994)]. A IHC, porm, vai muito alm do projeto de interfaces de sistemascomputacionais, ela abrange todos os aspectos relacionados interao entre usurios esistemas.

A rea de IHC tem por objetivo principal fornecer previses e explicaes sobre ainterao entre o usurio e o sistema e resultados prticos para o design da interface. Apartir desses resultados, os pesquisadores e desenvolvedores de sistemas podem aprimorara experincia do usurio [ACM SIGCHI, (1992) apud de Souza et al. (1999)].

A usabilidade vem sendo um fator central dentro de IHC. Segundo Rogers et al. (2011),usabilidade um conceito que busca melhorar a experincia do usurio, garantindo queprodutos interativos tenham efetividade no uso, sejam fceis de aprender e sejam praze-rosos da perspectiva do usurio. Para tanto, o autor explica que existem seis objetivos nausabilidade:

efetividade no uso: quo bom o produto em fazer o que se props a fazer;

ecincia no uso: produtividade que o usurio ganha medida que aprende osconceitos bsicos do produto interativo;

segurana no uso: capacidade do produto em evitar que os usurios cometamerros, por exemplo, separando aes crticas umas das outras; e possibilitar aosusurios que se recuperem de erros sempre que eles ocorram;

ter boa utilidade: conjunto de funes que o produto prov, habilitando os usu-rios a fazerem o que eles precisam ou querem fazer;

facilidade de aprendizado: quo fcil de usar o sistema , ou seja, se os usu-rios no precisam gastar muito tempo para aprender as funcionalidades bsicas dosistema;

facilidade de relembrar como se usa: quo fcil o usurio se lembra de comousar as funcionalidades bsicas do sistema.

Cada um desses objetivos pode ser avaliado por meio de perguntas, como, por exem-plo, no caso da ecincia no uso: os usurios, tendo aprendido como usar um produtopara realizar suas tarefas, conseguiro manter um alto grau de produtividade?. Essas

5

perguntas so naturalmente genricas para se adequar aos diferentes sistemas, mas devemser divididas em perguntas mais objetivas, em que se possa coletar dados quantitativospara avaliar a usabilidade do sistema, tal como: quanto tempo o usurio demora paralembrar como fazer determinada ao aps uma semana?.

Para de Souza et al. (1999), os desenvolvedores muitas vezes precisam identicar quaisdesses objetivos so prioritrios em relao aos outros para o sistema em questo, vistoque se torna dispendioso ser excelente em todos eles. Se os desenvolvedores denirem,por exemplo, a segurana no uso como o objetivo prioritrio, pode ser desenvolvido umsistema em que o usurio no consiga cometer erros, mas que tambm muitas vezes notenha muita liberdade de ao. Adler & Winograd (1992) apud de Souza et al. (1999)chamam estes sistemas de antiidiotas e armam que as tecnologias sero mais ecazesquando desenvolvidas para no substituir, mas aumentar as capacidades dos usurios.

Ainda de acordo com de Souza et al. (1999), mais recentemente algumas propostasenfatizam que alm da necessidade de se estudar a usabilidade, precisa-se tambm estudara aplicabilidade e a comunicabilidade, construindo, assim, um sistema fcil de se usar,aplicar e comunicar. Para [Fischer (1998) apud de Souza et al. (1999)]:

aplicabilidade: reside no fato de todo usurio ser especialista em um domnio e osistema deve servir sua especialidade e no o contrrio. O sistema, deve, portanto,funcionar como um utenslio para o usurio e no exigir que o usurio atenda sexigncias de peculiaridades tecnolgicas.

comunicabilidade de um sistema: a capacidade deste sistema comunicar osprincpios e intenes que guiaram o seu design. Junto com a usabilidade, a comu-nicabilidade pretende aumentar a aplicabilidade do software.

Dix et al. (1998) armam que devem-se considerar quatro elementos bsicos em umainterao entre humano e computador: o prprio sistema, os usurios, os desenvolvedorese o ambiente de uso (domnio de aplicao). E segundo de Souza et al. (1999), esseselementos esto envolvidos em dois processos importantes: a interao entre o usurio ea interface e o desenvolvimento do sistema. Com base nestes elementos, a IHC propecinco reas de estudos:

design e desenvolvimento do hardware e software : estudo de tecnologiasde comunicao fsica entre usurio e sistema (entrada e sada) e tecnologias desoftware, como ambientes grcos e virtuais;

estudo da capacidade e limitao fsica e cognitiva dos usurios: envolvendoconceitos de ergonomia e psicologia, avaliando limites de esforo fsico e cognitivodo usurio, tais como postura do usurio, altura dos dispositivos, memorizao,raciocnio e aprendizado;

instrumentao terica e prtica para o design e desenvolvimento desistemas interativos: envolve todo o conhecimento terico e prtico a respeitodos fenmenos possveis na interao usurio-sistema e disponibiliza modelos quedetalham etapas a serem seguidas durante o desenvolvimento do sistema, tais comodiretrizes, tcnicas, linguagens, formalismos e ferramentas de apoio que possamajudar o desenvolvedor;

6

modelos de interfaces e do processo de interao usuriosistema: de-senvolvimento de modelos abstratos da interao usurio-sistema compatveis comas capacidades e limitaes fsicas e cognitivas dos usurios, visando melhorar estainterao;

anlise do domnio e de aspectos sociais e organizacionais: avaliao doimpacto que o ambiente exerce no usurio sobre seus conhecimentos, sua linguageme suas necessidades.

2.1.2 Estilos de interao

Existem diversas formas de interagir com um computador. Para Preece et al. (1994),estilo de interao um termo genrico que engloba todas as possveis formas que umusurio pode interagir com um sistema computacional. Alguns exemplos de estilos deinterao, segundo de Souza et al. (1999), so:

linguagem natural;

linguagens de comando;

menus;

preenchimento de formulrio;

manipulao direta;

WIMP (Windows, Icons, Menus e Pointers).

A possibilidade de se comunicar com o sistema utilizando uma linguagem naturalj utilizada em diversos sistemas computacionais, ou seja, o usurio pode se comunicarna mesma linguagem dos seres humanos, seja no idioma portugus, no francs, no inglsou em qualquer outro. Essa forma de interao busca aproximar a aplicao forma queo usurio est acostumado a se comunicar, sendo, portanto, especialmente atrativa parausurios com pouco ou nenhum conhecimento de linguagens de computao.

Algumas interfaces utilizando linguagem natural podem ser desenvolvidas, por exem-plo, interpretando frases que o usurio digita ou mesmo fazendo o reconhecimento davoz. Essas interfaces, porm, precisam lidar com frases com problemas lxicos, sintti-cos e semnticos. Alm disso, esse tipo de linguagem consegue interpretar apenas umsubconjunto da linguagem natural.

As interfaces que se baseiam em linguagens de comando, ao contrrio daquelasbaseadas em linguagem natural, buscam aproximar o usurio do computador, recebendocomandos especcos, em linguagem bem prxima de mquina, como pode-se observarna Figura 2.2. Essas interfaces so normalmente mais difceis de serem aprendidas, porm,por outro lado, usurios especialistas nessas linguagens ganham enorme produtividade econtrole do sistema.

7

Figura 2.2: exemplo de linguagem de comando - Terminal do Linux.

Menus so interfaces que apresentam um conjunto de opes s quais o usurio podeselecionar para ter acesso s funcionalidades do sistema. Cada escolha de uma opono menu ir mudar o estado da interface. Assim, o usurio no precisa se lembrar ondeestava a opo, apenas reconhec-la. Para isso importante que o sistema facilite oreconhecimento, escolhendo textos auto-explicativos para cada opo.

Interfaces de preenchimento de formulrios so utilizadas, principalmente, paraa insero de dados em sistemas de informao. So normalmente simples de seremutilizadas, por serem bastante parecidas com os formulrios em papel aos quais os usuriosesto acostumados a utilizar. Esses formulrios precisam fornecer meios ao usurio devalidar os dados inseridos, pois so, geralmente, usados com grande frequncia e sopassveis de erros ao tratar os dados fornecidos pelo usurio.

As interfaces de manipulao direta so aquelas que permitem ao usurio interagirdiretamente com os objetos da aplicao, sejam eles dados ou representaes de objetosdo domnio. Essa interao feita normalmente por intermdio de um cursor (software0e de um mouse (hardware).

O estilo de interaoWIMP (acrnimo em ingls para janelas, cones, menus e apon-tadores) um conjunto dos outros estilos e uma juno de tecnologias de hardware esoftware. possvel encontrar nessas interfaces os estilos de menu, interao direta, ma-nipulao de formulrios e linguagens de comandos. A Figura 2.3 apresenta uma tela quefaz uso do estilo WIMP.

8

Figura 2.3: exemplo de interface WIMP. Fonte: adaptado de de Souza et al. (1999).

2.2 Avaliao de Interao Humano-Computador em

aplicaes Web

Existem diferentes teorias que pode-se fazer uso para avaliar sistemas computacionaissegundo tica da Interao Humano-Computador. Alguns mtodos de avaliao seutilizam de usurios reais, enquanto outros fazem uso de especialistas em IHC. Nessaseo sero analisados os principais mtodos de avaliao e quais so indicados a seremutilizados em cada situao.

2.2.1 Mtodos de avaliao

Existem diferentes formas de se classicar os mtodos de avaliao existentes. SegundoRogers et al. (2011), os mtodos podem ser divididos em trs grupos:

com a utilizao de usurios em ambientes controlados;

com a utilizao de usurios no prprio local de trabalho;

sem a utilizao de usurios.

Segundo Barbosa e Silva (2010), pode-se classicar os mtodos de avaliao em outrostrs grupos:

9

Avaliao por meio de investigao: o avaliador coleta a impresso dos usurios pormeio, por exemplo, de questionrios, entrevistas ou grupos focais. Dessa forma, oespecialista pode avaliar o design e encontrar problemas que podero ocorrer quandoo sistema estiver em funcionamento. Tambm possvel coletar as expectativas dosusurios sobre o sistema analisado;

Avaliao por meio de inspeo: o avaliador busca se colocar no lugar do usu-rio enquanto examina o sistema, porm, no possui participao de usurios reais.Exemplos:

avaliao heurstica: utilizada para vericar se o sistema atende aos requisitosde usabilidade;

percurso cognitivo: tem como principal objetivo vericar a facilidade de apren-dizado de um sistema (aprender fazendo);

mtodo de inspeo semitica: aborda a comunicabilidade do sistema e a qua-lidade da emisso da metacomunicao que o designer colocou na interface.

avaliao por observao: o avaliador coleta dados com usurios em situaes reaisde uso, para identicar problemas que ocorreram. Exemplos:

teste de usabilidade: visa analisar se o sistema atende a requisitos de usabili-dade;

mtodo de avaliao de comunicabilidade: consiste em avaliar a qualidade dacomunicao da meta-mensagem do designer para os usurios;

prototipao em papel: desenvolvido um prottipo em papel para que osusurios possam interagir e avaliar o sistema, como pode-se vericar no exemploda Figura 2.4.

10

Figura 2.4: exemplo de prottipo em papel. Fonte: Barbosa e Silva (2010).

Os mtodos de investigao normalmente envolvem entrevistas, estudos de campo,questionrios, dentre outras ferramentas. Assim, possvel avaliar janelas, problemasusuais e ter ideias do que esperado do sistema. H ainda a possibilidade de utilizaocom vistas a analisar como ser a aceitao dos usurios quando o sistema estiver pronto.

Com mtodos de inspeo pode-se analisar futuros problemas que o design pode oca-sionar ao ser utilizado pelos usurios nais. Com isso, possvel construir designs alter-nativos para se encontrar a melhor soluo. Neste mtodo, o avaliador se posiciona comoum usurio, buscando encontrar os problemas que este teria. Como os avaliadores noso os reais usurios, pode haver problemas que no so percebidos por estes e outrosque, embora encontrados pelos avaliadores, no so relevantes para os utilizadores reais.Um dos principais mtodos de inspeo a avaliao heurstica, que um mtodo parase encontrar problemas de usabilidade. Nielsen (2003) apud Barbosa e Silva (2010) listaum conjunto de caractersticas que devem ser utilizados nesse mtodo de avaliao:

visibilidade do estado do sistema: o usurio deve saber o que est acontecendo nosistema;

correspondncia entre o sistema e o mundo real: linguagem de fcil acesso, de formalgica que seja amigvel para os usurios;

11

controle e liberdade do usurio: existncia de uma sada de emergncia, tal comoum boto retornar;

consistncia e padronizao: palavras em locais diferentes devem ter o mesmo sig-nicado, tentando manter os padres j conhecidos pelos usurios;

reconhecimento em vez de memorizao: deve-se ter os pontos principais do sistemasempre de fcil acesso, no sendo necessrio decorar os locais em que esto;

exibilidade e ecincia de uso: criao de atalhos e botes que facilitem a vida deusurios mais experientes;

projeto esttico e minimalista: interface limpa, somente com o essencial;

preveno de erros: evitar ter problemas no sistema;

ajuda os usurios a reconhecerem, diagnosticarem e se recuperarem de erros: usode mensagens simples, sugerindo meios de resolver o problema encontrado;

ajuda e documentao: um sistema ideal no deveria necessitar de documentao,mas caso o usurio precise, que a documentao esteja de fcil acesso, com linguagemsimples e com informaes em poucas palavras.

Para Barbosa e Silva (2010), as atividades de uma avaliao heurstica so as seguintes:

Figura 2.5: atividades de uma avaliao heurstica. Fonte: Barbosa e Silva (2010)

Os mtodos de observao so realizados com usurios reais, enquanto utilizam osistema. Os dados coletados so, em sua maior parte, focados em problemas encontradospelas pessoas avaliadas. Pode ser realizado em laboratrio ou em campo, sendo que emlaboratrio normalmente realizado um roteiro para que a pessoa mantenha o foco nospontos que devero ser avaliados, enquanto que em campo, so coletados mais dados e

12

de forma ampla j que os fatores que inuenciaro no sistema nal esto tambm sendotestados.

Salgado (2006) apud Barbosa e Silva (2010) diz que um teste realizado com mtodosde inspeo gasta menos da metade do tempo de uma avaliao com participao deusurios reais. Ao se comparar essas duas abordagens percebe-se que so parecidas deforma que a importncia maior das duas se d na avaliao com ou sem usurios. Poderoainda ser utilizadas combinaes desses mtodos, de forma que um determinado aspectoseja avaliado por um mtodo diferente ao que ser utilizado no sistema como um todo,fazendo-se necessrio que os pesquisadores denam quais so os mtodos mais adequados.

2.2.2 Comparativo dos mtodos de avaliao

Pode-se comparar os mtodos de avaliao citados anteriormente de diferentes formas.Na Figura 2.6 a classicao varia de inadequado () a muito adequado (+++).

Figura 2.6: aspectos geralmente avaliados por meio de cada mtodo. Fonte: Barbosa eSilva (2010).

Como pode-se vericar na Figura 2.6, o Mtodo de Inspeo Semitica (MIS) e oMtodo de Avaliao de Comunicabilidade (MAC), ambos da Engenharia Semitica, somuito adequados de serem utilizados para vericao de problemas de IHC, porm, soinadequados de serem utilizados para vericao de conformidade com algum padrodenido anteriormente.

Segundo Barbosa e Silva (2010), possvel se avaliar em dois momentos distintos:

durante o desenvolvimento do sistema, que busca coletar dados para reorientar oprprio desenvolvimento do produto, antes de estar pronto. A esse tipo de avaliaod-se o nome de formativa;

depois que o sistema j estiver nalizado, buscando avaliar quo distante o produtonal cou de metas especcas. A esse tipo de avaliao se d o nome de somativa.

13

Na Figura 2.7, verica-se a frequncia em que os mtodos so utilizados em cada umdos tipos de avaliao: somativa ou formativa. A escala utilizada representa a intensidade,sendo que (++) indica um uso mais frequente do mtodo.

Figura 2.7: quando cada mtodo de avaliao costuma ser utilizado. Fonte: Barbosa eSilva (2010).

Na Figura 2.8 Barbosa e Silva (2010) apresentam uma anlise dos tipos de dadosproduzidos de acordo com o mtodo de avaliao utilizado, sendo que (+++) indica umuso mais adequado do mtodo.

14

Figura 2.8: tipos de dados produzidos por cada mtodo de avaliao. Fonte: Barbosa eSilva (2010).

Como podemos vericar, o MIS e o MAC geram dados prioritariamente qualitativos,no tendo um foco na anlise quantitativa dos dados coletados, e sim na qualidade destes.

2.2.3 Planejamento da avaliao de IHC

Avaliao de modo geral diagnosticar e intervir, o que quer dizer praticar a inves-tigao sobre o que est acontecendo, tendo em vista proceder intervenes adequadas,sempre para a melhoria dos resultados [Luckesi (2005)]. Esse conceito amplo da rea deensino pode ser uma breve introduo sobre avaliaes nesse trabalho.

Conforme Barbosa e Silva (2010), a avaliao em IHC ocorre no momento em queo avaliador faz um julgamento de valor sobre a qualidade de uso da soluo de IHC eidentica problemas na interao e na interface que prejudicam a experincia particulardo usurio durante o uso do sistema.

Nessa parte sero analisados os seguintes aspectos da avaliao:

Por que avaliar?

O que avaliar?

Quando avaliar o uso de um sistema?

15

Onde coletar dados sobre experincias de uso?

Que tipos de dados coletar e produzir?

Qual tipo de mtodo de avaliao escolher?

Como avaliar?

Por que avaliar?

Existem diferentes por ques que levam a se fazer avaliaes de sistemas computaci-onais. Segundo Barbosa e Silva (2010), os principais motivos so que:

nem sempre os produtos desenvoldidos a partir de um processo so de qualidade;

no desenvolvimento de sistemas interativos natural que ocorram erros.

Alm dos itens elencados acima, a avaliao tambm pode vericar solues alternati-vas de design, vericar se o sistema realmente o que o usurio precisa, dentre outros. Naengenharia de software, o objetivo principal das avaliaes vericar o sistema de acordocom as especicaes dos requisitos, enquanto em IHC o foco da avaliao saber se osistema apoia adequadamente os usurios a atingirem um determinado objetivo em umcontexto de uso.

O que avaliar?

Conforme Rogers et al. (2011), atualmente, os usurios esperam muito mais do quesistemas que funcionem. Eles esperam ter experincias agradveis e facilidade ao manusearnovos sistemas. Para isso interessante que sejam avaliados desde prottipos de baixadelidade, funes, janelas de um software, a sistemas completos, podendo ser avaliadosvrios aspectos como segurana e questes estticas. Assim pode surgir a necessidade dese avaliar praticamente tudo.

O que ser avaliado depende primordialmente dos objetivos da avaliao desejada.Barbosa e Silva (2010) armam que a avaliao pode ter trs focos principais:

foco no sistema:

funcionalidade (se sistema faz o que o usurio precisa);

interatividade (o sistema de fcil manuseio para o pblico-alvo);

comunicabilidade (se a mensagem do designer entendida pelos usurios).

foco no usurio:

desempenho;

memorizao;

planejamento;

satisfao.

foco na acessibilidade (saber se todos podem utilizar o sistema).

16

Quando avaliar o uso de um sistema?

Barbosa e Silva (2010) armam que possvel avaliar em dois momentos: em tempo deprojeto (avaliao formativa) e com o sistema pronto (avaliao somativa ou conclusiva).Em tempo de projeto, a avaliao visa corrigir eventuais problemas antes de o sistema estarpronto, sendo que este tipo de avaliao, normalmente, realizado com poucas pessoas,que so potenciais usurios do sistema. Por outro lado, a avaliao com o sistema pronto,ou com um prottipo de mdia ou alta delidade, verica se foram cumpridos os requisitosdo usurio e busca falhas de projeto. Nem sempre as causas das falhas so descobertas,apenas so levantados os problemas que ocorerram.

Onde coletar dados sobre experincias de uso?

Faz-se necessrio, tambm, se atentar sobre onde coletar os dados para a avaliao, quepode ser em um laboratrio adequado para medies ou em campo, no local de trabalhodo avaliado. Para Rogers et al. (2011) e Barbosa e Silva (2010), avaliaes realizadasem laboratrio facilitam o registro de dados das experincias, pois como um ambientepreparado para tal m, qualquer interferncia pode ser evitada ou minimizada. Assim,nesse tipo de ambiente, o avaliado conseguir se manter mais focado na sesso de avaliao.Pode-se ver um exemplo de um ambiente de laboratrio na Figura 2.9.

Figura 2.9: exemplo de laboratrio para observar um participante utilizando um sistemacomputacional interativo. Fonte: Barbosa e Silva (2010).

Por outro lado, a avaliao em campo se aproxima mais da realidade, propiciandoexperincias que podem acontecer na utilizao real da soluo apresentada. Assim,dados sobre o ambiente do usurio podem ser coletados, que em laboratrio seria difcilou invivel de se obter.

Em alguns tipos de teste, tais como os de usabilidade e comunicabilidade, essencialque haja um local preparado para que sejam notados detalhes que em uma anlise de

17

campo seria difcil de se obter. Assim, necessrio saber o que se deseja avaliar para queseja escolhido o melhor local para coleta dos dados.

Que tipo de dados coletar e produzir?

Segundo Barbosa e Silva (2010), existem vrias maneiras de classicao dos dadoscoletados, sendo as mais comuns:

nominais, ordinais, de intervalo e de razo;

dados qualitativos e quantitativos;

subjetivos e objetivos.

Dados nominais so do tipo rtulos, tais como o sexo da pessoa: masculino ou feminino;e estado de nascimento: Bahia, Sergipe etc. Dados ordinais so dados que possibilitamque sejam colocados em ordem, por exemplo, canais mais assistidos pelo usurio, stiosmais navegados etc. Dados de intervalo podem ser considerados faixas de dados ordinais,por exemplo, os dois canais mais assistidos pela pessoa, os cinco stios mais acessados etc.Dados de razo so os que podero ser analisados apenas comparativamente, mesmo quetal comparao seja com zero. Como exemplo deste ltimo tipo pode-se citar a quantidadede erros em uma interface, o tempo que leva para dois usurios realizarem determinadatarefa etc.

Os dados qualitativos so aqueles que no so possveis de se analisar quantitativa-mente, tais como respostas abertas, crticas, sugestes etc. Enquanto que os quantitativosso os que podem ser colocados em uma ordem numrica, tal como tempo gasto, nmerode cliques do mouse para se realizar determinada tarefa etc.

E por m a classicao em dados objetivos pode ser entendida como os dados quepodem ser coletados sem que o usurio precise expressar nada pessoal, apenas cumprir oque solicitado, tais como as palavras utilizadas para se encontrar uma msica na Internet.Enquanto que dados subjetivos remetem opinio do usurio e suas preferncias.

Como avaliar?

Para se realizar avaliaes, h de se levar em conta vrios aspectos, por exemplo, adisponibilidade de usurios, a nalidade dos testes e a quantidade de tempo/dinheironecessrios. Existem quatro paradigmas que podem orientar a forma de aplicao destasavaliaes. So eles:

rpido e rasteiro (informal);

testes de usabilidade em laboratrios;

estudos em campo (no dia a dia, durante a rotina normal, por isso so difceis decontrolar);

avaliao preditiva (baseada em heursticas).

No paradigma rpido e rasteiro, a avaliao ser realizada com pessoas com maisconhecimento em usabilidade ou com potenciais usurios do sistema nal a m de se

18

conrmar se o desenvolvimento est seguindo pelo caminho ideal. Neste paradigma, aavaliao rpida e informativa, mas no existem muitos cuidados formais.

Os testes de usabilidade realizados em laboratrio tm de ser realizados com usuriosreais, ou potenciais, e devem ser registrados. Este tipo pode ser realizado em campotambm, dependendo dos objetivos que se esperam alcanar. Nesses testes solicitado aousurio que realize determinadas tarefas para que, dessa forma, o seu desempenho sejaavaliado. Os registros podem ser lmagens do usurio, tela, log da interao na interfaceutilizada, interjeies (falas), sons emitidos, gestos, at mesmo olhares e alguns detalhesmusculares. Pode-se medir ainda o grau de satisfao com entrevistas, questionrios eoutros mtodos.

Estudos de campo so normalmente realizados no local de trabalho dos usurios,avaliando-se o sistema que eles utilizam no seu dia a dia. Neste tipo de avaliao, no sopropostas tarefas, apenas observada a interao do usurio com os artefatos tecnolgi-cos. Serve para entender como o usurio manipula o sistema, identicar tecnologias queso utilizadas, denir mais requisitos de projeto e realizar coletas de dados que poderoser teis posteriormente.

Nas avaliaes do tipo preditiva, necessrio conhecer os usurios para que se possaprever a forma que eles utilizaro o sistema. Este tipo de avaliao no realizada comusurios. H apenas uma suposio de algum especialista sobre o que os usurios fariamou achariam dos artefatos. Existem tambm alguns modelos que podem ser utilizadosa m de se prever como seria a utilizao dos usurios e os problemas que poderiamenfrentar.

Para realizar avaliaes, uma tcnica que traz bons resultados a Think Aloud, emportugus pense alto. Essa tcnica consiste em que o usurio fale o que quer que estejaolhando, pensando, fazendo ou sentindo durante a execuo de uma tarefa. A avaliaodeve ser lmada para que posteriormente os vdeos possam ser analisados a m de formarum modelo cognitivo do que o usurio estava pensando durante a execuo da tarefa(Someren et al. (1994)). Dessa forma, a utilizao da tcnica Think Aloud proporciona osurgimento de informaes que no poderiam ser facilmente obtidas.

Dumas e Redish (1999) apud Barbosa e Silva (2010) dizem que uma avaliao de IHCem geral deve envolver de cinco a doze usurios, enquanto Nielsen (2000) apud Barbosae Silva (2010) arma que possvel encontrar a maioria dos problemas da interface comapenas cinco usurios. importante tambm ter em mente que o mtodo de avalia-o escolhido tambm inuenciar o nmero de participantes. Um mtodo puramentequalitativo, por exemplo, no exigir uma grande quantidade de participantes.

2.2.4 Framework DECIDE

O Framework DECIDE foi desenvolvido com o objetivo de guiar a preparao e exe-cuo de avaliaes em IHC [Preece et al. (1994)]. Essa ferramenta dene seis passos quedevem ser seguidos iterativamente no decorrer do planejamento dos objetivos da avalia-o. Cada uma das letras que denem o nome do framework a inicial de um dos passosna verso em ingls. Segundo Barbosa e Silva (2010) os seis passos do DECIDE podemser resumidos da seguinte forma:

(D) Determinar os objetivos da avaliao de IHC (Determine the goals). O Avaliadordeve determinar os objetivos gerais da avaliao e identicar por que e para quem tais

19

objetivos so importantes. O restante do planejamento da avaliao, sua execuoe a apresentao dos resultados sero orientados por esses objetivos.

(E) Explorar perguntas a serem respondidas com a avaliao (Explore the questi-ons). Para cada objetivo denido, o avaliador deve elaborar perguntas especcas aserem respondidas durante a avaliao. Essas perguntas so responsveis por ope-racionalizar a investigao e o julgamento de valor a serem realizados. Elas devemconsiderar o perl dos usurios-alvo e suas atividades.

(C) Escolher os mtodos de avaliao a serem utilizados (Choose the evaluationparadigm). O avaliador deve escolher os mtodos mais adequados para responderas perguntas e atingir os objetivos esperados, considerando tambm o prazo, o or-amento, os equipamentos disponveis e o grau de conhecimento e experincia dosavaliadores.

(I) Identicar e administrar as questes prticas da avaliao (Identify the practicalissues). Existem muitas questes prticas envolvidas numa avaliao de IHC, como,por exemplo, o recrutamento dos usurios que participaro da avaliao, a prepara-o e o uso dos equipamentos necessrios, os prazos e o oramento disponveis, almda mo-de-obra necessria para conduzir a avaliao.

(D) Decidir como lidar com questes ticas (Decide how to deal with the ethicalissues). Sempre que usurios so envolvidos numa avaliao, o avaliador deve tomaros cuidados ticos necessrios. Os participantes da avaliao devem ser respeitados eno podem ser prejudicados direta ou indiretamente, nem durante os experimentos,nem aps a divulgao dos resultados da avaliao.

(E) Avaliar, interpretar e apresentar os dados (Evaluate, interpret, and present thedata). O avaliador precisa estar atento a alguns aspectos da avaliao realizadaantes de tirar concluses e divulgar resultados. Ele deve considerar: o grau deconabilidade dos dados (i.e., semelhana dos resultados obtidos quando empregamais de uma vez o mtodo de avaliao nas mesmas circunstncias); a validadeinterna do estudo (i.e. se o mtodo de avaliao mede o que deveria medir, se ofaz com rigor e evita que os dados sejam distorcidos); a validade externa do estudo(i.e., at que ponto os resultados podem ser generalizados ou transferidos a um outrocontexto semelhante); e a validade ecolgica do estudo (i.e., o quanto os materiais,mtodos e ambiente de estudo se assemelham situao real investigada).

Caso a avaliao no transcorra como o planejado, o framework deve ser modicadopois as demais atividades podem ser afetadas.

2.2.5 Engenharia Semitica

A Engenharia Semitica uma inovao na rea de IHC, proposta por Clarisse Si-eckenius de Souza, nomeada em 2013 como pesquisadora da CHI Academy, que se tratade um grupo de pesquisadores homenageados pelo SIGCHI (Special Interest Group inComputerHuman Interaction of the Association for Computing Machinery1).

1http://www.sigchi.org/

20

Segundo de Souza (2005), esta rea foi originalmente proposta como uma abordagemsemitica para a criao de linguagens de interface do usurio. Ao longo dos anos, compesquisa realizada no Departamento de Informtica da Pontifcia Universidade Catlicado Rio de Janeiro (PUC-RJ), a rea evoluiu para uma teoria semitica da InteraoHumano-Computador.

Segundo de Souza (2005), uma das principais vantagens da viso semitica sobre aIHC centralizar a ateno dos pesquisadores nos signos. Esta teoria possibilita entendero processo de desenvolvimento, uso e avaliao de sistemas computacionais [Prates eBarbosa (2007)]. A Engenharia Semitica avalia como est a comunicao entre o que odesigner quis enviar como mensagem e o que o usurio entendeu, possibilitando assim umaavaliao que ajudar aquele a tomar decises de aprimoramento para o sistema. No papel da Engenharia Semitica listar possveis solues para os problemas encontrados,apenas mostrar onde esto as falhas na comunicao.

A Engenharia Semitica baseada na Semitica que, de acordo com Santaella (1983), a cincia dos signos, tendo Peirce como um dos seus idealizadores. Peirce (1998) armavaque o principal conceito na Semitica o signo, que tudo aquilo que signica algo paraalgum, ou seja, toda e qualquer representao, verdadeira ou falsa, de um conceito ouobjeto que ser decifrado em um interpretante, como ilustrado na Figura 2.10.

Figura 2.10: denio de signo segundo Peirce. Fonte: Peirce (1998) (modicado).

importante ressaltar que o signo pode possuir diferentes signicaes, dependendode quem o interpreta, e cada uma dessas signicaes o que chamamos de interpre-tante. Alm disso, um objeto pode possuir diferentes signos para o representar. Umarepresentao, por exemplo, de um cachorro, pode ser feita por meio de uma foto, de umlatido, da palavra cachorro escrita ou falada ou de um desenho, mas todos so signosrepresentando um mesmo objeto.

Um interpretante pode por sua vez gerar outro interpretante. Se um emissor falarsobre o carro dele, pode-se pensar em nosso prprio carro, que em seguida pode nos levara pensar em um carrinho de brinquedo que ganhamos em um aniversrio, que pode noslevar a pensar na festa de aniversrio, e assim por diante. Cada uma dessas signicaes um interpretante e a essa sequncia indenida damos o nome de semiose ilimitada,como ilustrado na Figura 2.11 [Prates e Barbosa (2007)].

21

Figura 2.11: semiose ilimitada. Fonte: Prates e Barbosa (2007).

Prates e Barbosa (2007) armam que os dois conceitos mais importantes dentro daSemitica so os de signicao e comunicao:

Signicao o processo de criar expresso e contedo de signos baseado emconvenes culturais e sociais, ou seja, os signos gerados esto intrinsecamente co-nectados ao ambiente que os envolve. A esta relao entre expresso e contedo sed o nome de sistemas de signicao [Eco (1976) apud Prates e Barbosa (2007)].

O ato de colocar o polegar para cima, por exemplo, pode ter signicados totalmentediferentes dependendo da cultura dos indivduos. Pode-se tambm criar signos deforma articial, que o que ocorre no desenvolvimento de software. A imagem comum X para fechar a janela do Windows, Figura 2.12, foi criada arbitrariamentee mesmo assim um signo, pois signica o conceito de fechar a janela e gera uminterpretante no usurio.

Figura 2.12: signos tradicionais do Windows.

Comunicao o processo de criar mensagens, composta por signos de um oumais sistemas de signicao, entre os interlocutores (emissores e receptores). Essasmensagens trafegam dentro de um canal e esto sujeitas a rudos, ou seja, diferentesnveis de obstculos para a comunicao dentro do canal escolhido, como ilustradona Figura 2.13.

22

Figura 2.13: processo da comunicao.

Outro conceito importante que a Engenharia Semitica usa como base o de consideraro software como um artefato intelectual. Segundo de Souza (2005), para ser consideradoum artefato intelectual o objeto de estudo precisa satisfazer aos seguintes princpios:

deve codicar uma interpretao de uma situao;

deve codicar uma ou mais solues da situao identicada;

deve ser codicada em uma linguagem especca, ou seja, um conjunto de relaesentre smbolos;

os usurios devem ser capazes de utilizar o sistema, entendendo a linguagem na quala soluo foi codicada.

Um software, portanto, se enquadra na denio de artefato intelectual, pois a co-dicao de uma ou mais possveis solues, da viso do projetista, de uma situaoespecca, desenvolvida em uma linguagem de programao, em que usurios podem usu-fruir dessas solues por meio da interpretao que o computador faz do que o projetistacodicou.

A Engenharia Semitica entende o software, desenhado pelo projetista, como umamensagem para o usurio, em que este usurio, por sua vez, ir capt-la de forma as-sncrona, dando origem a uma metacomunicao, pois a mensagem que passada aousurio relativa prpria comunicao. De acordo com de Souza (2005), esta comuni-cao entre o projetista e o usurio da forma:

Esta a minha interpretao sobre quem voc , o que eu entendi que voc quer ouprecisa fazer, de que formas prefere faz-lo e por qu. Eis, portanto, o sistema queconsequentemente concebi para voc, o qual voc pode ou deve usar assim, a m derealizar uma srie de objetivos associados com esta (minha) viso.

Essa mensagem, porm, indireta e unidirecional, visto que o usurio no pode darcontinuidade comunicao que o projetista inicia. Alm disso, ela mostrada aos pou-cos ao usurio, que, medida que navega na soluo apresentada, vai assimilando essamensagem que o projetista deixou no sistema.

Segundo Prates et al. (2000), ainda importante o conceito de comunicabilidadeque a Engenharia Semitica dene como a busca por evidenciar a capacidade do projetistade transmitir aos usurios, por meio da interface, o design tal como foi concebido por ele.

23

A Engenharia Semitica, no momento deste trabalho, possui dois mtodos de avaliaopara avaliar a qualidade da metacomunicao em IHC: o Mtodo de Avaliao deComunicabilidade (MAC) e oMtodo de Inspeo Semitica (MIS), que so ambosmtodos qualitativos [de Souza et al. (1999)].

O MAC se prope a avaliar a comunicabilidade do sistema computacional com autilizao de usurios reais. Nesse mtodo so feitas gravaes das interaes dessesusurios com o sistema para posterior anlise minuciosa dos problemas encontrados.

O MIS faz uso de prossionais especialistas em IHC para avaliar a comunicabilidadedo sistema. Estes prossionais iro avaliar o que os designers quiseram passar para osusurios com cada um dos signos estticos e dinmicos e gerar um relatrio dos problemasencontrados.

Como este trabalho fez uso do MAC, esse mtodo ser detalhado na seo seguinte.

2.2.6 Mtodo de Avaliao de Comunicabilidade

O Mtodo de Avaliao de Comunicabilidade (MAC) baseado na Engenharia Semi-tica, ou seja, considera o sistema como uma mensagem, composta de signos, do designerpara o usurio. Foi o primeiro mtodo proposto pela Engenharia Semitica para realizaranlise de metacomunicao [de Souza e Leito (2009)]. Porm, enquanto a EngenhariaSemitica se preocupa com a emisso da metamensagem, o MAC avalia a qualidade darecepo desta pelo usurio.

Para Barbosa e Silva (2010), o foco da anlise abrange os provveis caminhos de in-terpretao dos usurios, suas intenes de comunicao e, principalmente, as rupturasde comunicao que ocorreram durante a interao. Como resultado, os avaliadores iden-ticam problemas na comunicao da metamensagem do designer e na comunicao dousurio com o sistema, alm de ajudar a informar o designer as causas dessas falhas.

O MAC baseia-se na interpretao de um vdeo do usurio, utilizando o sistema, ouprottipo, com o objetivo de se identicar falhas durante a utilizao [de Souza e Leito(2009)]. Na sesso de avaliao o usurio deve realizar um conjunto de tarefas que sopassadas a ele.

De acordo com Barbosa e Silva (2010) as atividades do MAC esto respresentadas naFigura 2.14.

24

Figura 2.14: atividades do Mtodo de Avaliao de Comunicabilidade. Fonte: Barbosa eSilva (2010).

A seguir tem-se uma breve descrio das etapas de uma avaliao com o Mtodo deAvaliao de Comunicabilidade:

preparao: nesta etapa so denidos os objetivos, quais mtodos sero utilizados equal o perl e nmero de participantes desejados. Nessa parte o avaliador tambmpode realizar um teste-piloto a m de vericar se a avaliao condizente com oresultado esperado e se os dados coletados conseguiro responder s questes e ob-jetivos do estudo. Deve-se conrmar o bom funcionamento de softwares de gravaoe preparar o material relacionado tarefa que o participante dever realizar;

coleta de dados: a coleta deve ocorrer conforme o planejamento e o mtodo deavaliao selecionado. Deve-se tentar passar tranquilidade ao avaliado e coletar omximo de informaes possvel da avaliao. No decorrer dessa atividade, socoletados os dados demogrcos e as informaes ps-teste;

interpretao: nessa atividade, o avaliador ir analisar o material obtido na coletade dados com vistas a atribuir um signicado a eles. Nessa etapa o pesquisadordever atribuir etiquetas s falhas de comunicao encontradas;

consolidao dos resultados: ser realizada fazendo uma comparao dos dadoscoletados. Segundo de Souza (2005), h alguns fatores que devem ser consideradosao realizar esta comparao:

a frequncia e o contexto em que ocorre cada etiqueta com vistas a identicarproblemas recorrentes;

sequncia de etiquetas, que pode indicar uma ruptura maior, que necessita demais tempo para retornar a um caminho produtivo;

25

o nvel dos problemas dos usurios dependendo de seus objetivos (ttico, ope-racional ou estratgico);

outras abordagens e tcnicas de IHC que podem melhorar a interpretao dopesquisador.

relato dos resultados: deve conter descrio geral da avaliao, mtodos utilizados,informaes sobre os usurios escolhidos, qual foi a tarefa realizada. importante,caso tenham sido feitas modicaes no sistema, que sejam justicadas e que sejaminformados os pontos que podem ser modicados para facilitar o entendimento dosusurios.

Aps a interpretao dos dados referentes a todos os avaliados, o pesquisador devecriar o perl semitico do sistema. O perl semitico a construo da metamensagemrecebida pelo usurio sobre o sistema. de Souza (2005) arma que perl semitico a reconstruo da metamensagem do designer, que resumidamente pode ser feito poranalogia a esse modelo:

Este o meu entendimento como designer, de quem voc, usurio , do que aprendique voc quer ou precisa fazer, de que maneiras prefere fazer, e por qu. Este portanto, o sistema que projetei para voc, e esta a forma como voc pode ou deve utiliz-lo paraalcanar uma gama de objetivos que se encaixam nesta viso.

Nesse modelo h o entendimento do designer sobre a quem o sistema se destina ecomo deve se fazer para atingir os objetivos que se pensa que o usurio tem. Com o perlsemitico constri-se a viso geral do designer sobre o usurio.

Segundo Prates e Barbosa (2007), so treze as etiquetas do Mtodo de Avaliao deComunicabilidade:

Cad?: esta etiqueta aparece quando o usurio busca realizar uma ao na interface,mas no sabe onde encontr-la. Um exemplo dessa ruptura se d quando o usurio tentavoltar para a pgina inicial do sistema, porm no consegue encontrar um boto que faaesta ao.

U, o que houve?: ocorre quando o sistema no d nenhum retorno ao dousurio ou o avaliado no percebe esse retorno. encontrada quando, por exemplo, oparticipante seleciona o boto Enviar em um formulrio e nada acontece.

E agora?: encontrada quando o participante no sabe o que fazer em seguida. Umexemplo dessa etiqueta ocorre quando o usurio se encontra no meio de uma tarefa e, noconseguindo realiz-la, comea a vagar pelo sistema.

Epa!: essa falha ocorre no momento em que o participante percebe que realizouuma ao indesejada e, imediatamente, a desfaz. Essa ruptura pode ser encontrada, porexemplo, quando o usurio entra em uma pgina equivocadamente e logo aperta o botovoltar do navegador.

Assim no d.: ocorre quando o usurio tenta seguir por um caminho e, ao nalde algum tempo e algumas interaes, percebe que no conseguir o resultado desejado.Decide, ento, voltar para o incio, ou algum outro ponto intermedirio, para seguir poroutro caminho.

Onde estou?: quando o usurio est dizendo coisas para o sistema que seriam apro-priadas em outro contexto, mas no naquele. Essa etiqueta encontrada, por exemplo,quando o participante tenta acessar uma opo que est desabilitada por causa do estadoatual que ele se encontra.

26

O que isto?: o usurio no sabe o que signica um determinado signo, ou, porexemplo, est com dvida se um link ou no. Um caso tpico dessa falha de comunicaoacontece quando o usurio para o mouse sobre um elemento da interface, aguardando poralguma dica de seu signicado.

Por que no funciona?: o participante insiste em repetir uma tarefa que no produzo efeito esperado. Ele est ciente de que o efeito no foi produzido e que outro foi produzidono lugar. Diferentemente da etiqueta U, o que houve?, essa falha produz um resultadovisvel ao usurio, que apenas no entende porque no acontece o que ele deseja.

Socorro!: o usurio no consegue realizar uma tarefa e busca informaes por meiode sistemas de ajuda para auxili-lo a conclu-la. Quando ele, por exemplo, acessa oscontedos que explicam como fazer determinada ao dentro do sistema, um caso queessa falha ocorre.

Vai de outro jeito!: o usurio no entende o caminho preferencial que o designergostaria que ele seguisse. Por isso, segue por um outro caminho que, normalmente, maislongo. Um exemplo dessa falha acontece quando o usurio no encontra o boto de voltarpara a pgina inicial e decide usar o boto voltar do navegador.

No, obrigado.: o usurio entende o caminho preferencial desenvolvido pelo designer,porm, mesmo assim, decide seguir pelo caminho alternativo. Normalmente, essa falhasignica que o caminho tido como preferencial no o melhor possvel. Pode-se usar comoexemplo a situao em que o usurio mesmo conhecendo os botes de atalho para fazeruma ao, prefere acessar as opes na barra superior e selecionar o item desejado.

Para mim est bom...: o participante completa a tarefa com algum erro, masacredita que a tarefa foi concluda com sucesso. Essa informao pode ser coletada noQuestionrio Ps-Teste. O usurio pode chegar a essa falha sempre que pular algumaetapa da tarefa que recebeu.

Desisto.: O usurio acredita que no conseguir completar a tarefa e interrompe ainterao, desistindo de cumpr-la. Podem existir diferentes causas, dentre elas: falta deconhecimento, de pacincia, de informao necessria ou de tempo.

2.3 Acessibilidade Web

Nesta seo ser analisada a acessibilidade segundo dois grupos de trabalho: o Con-srcio W3C e o governo brasileiro.

2.3.1 Recomendaes de acessibilidade do Consrcio W3C

O Consrcio World Wide Web (W3C) uma instituio internacional em que orga-nizaes liadas, uma equipe em tempo integral e o pblico, trabalham em conjunto,desenvolvendo padres para a World Wide Web (WWW ou Web). A misso do W3C conduzir a Web para que atinja todo o seu potencial, criando protocolos e diretrizes quegarantam seu crescimento a longo prazo 2.

Segundo Berners-Lee (2010), existem alguns princpios que so a chave para assegurarque a Web se torne cada vez mais valiosa, sendo os principais em relao sua utilidadee seu crescimento. Os usurios precisam poder criar elos para qualquer pgina na rede

2http://www.w3.org/Consortium/

27

http://www.w3.org/Consortium/

mundial de computadores, no importando qual computador eles possuem, qual softwareeles utilizem, qual idioma eles falem ou ainda se eles possuem acesso Internet com ousem o.

O uso dos padres na WWW, como foram denidos no seu incio na dcada de 90,segue os princpios levantados por Berners-Lee. Atualmente o W3C dene os seguintesprincpios para a Web 3:

Web para todos: o valor social da www que ela permite o acesso de qualquer pessoaindependentemente de posio geogrca, cultura, lngua nativa, software, hardware,velocidade de conexo com a Internet ou capacidade fsica e mental. Neste contexto,se faz necessria a denio de padres para, por exemplo, uma maior acessibilidadeaos usurios;

Web em tudo: o nmero de diferentes tipos de dispositivos que acessam a Webcresce a cada dia, tais como: celulares comuns, smartphones, tablets, televisesinterativas, sistemas de resposta por voz e diversos eletrodomsticos. Por isso, de suma importncia que a Web possa ser acessada desses diferentes dispositivos,exigindo-se assim uma padronizao de interpretao, por exemplo, do HypertextMarkup Language (HTML).

Ainda segundo Berners-Lee (2010), a WWW, como se conhece hoje, est sendo amea-ada de diversas formas. Grandes redes sociais esto bloqueando as informaes postadaspor seus usurios para o resto da Web. Provedores de Internet esto tentados a diminuira velocidade da conexo para stios da Web que no fecharam acordo com eles. Gover-nos totalitrios esto monitorando os hbitos online das pessoas, colocando em perigoimportantes direitos humanos.

O W3C desenvolve recomendaes para desenvolvimento de aplicaes Web, incluindoHTML5, CSS3, Ajax, SVG e diversas outras tecnologias 4. Alm disso, o consrcio de-senvolve tambm tecnologias para habilitar o acesso Web de qualquer lugar, a qualquermomento, usando qualquer tipo de dispositivo 5.

As pessoas que acessam a Web no tm um padro denido, possuem necessidadesdiferentes e podem ter algum tipo de diculdade, como no caso dos idosos e de pessoascom alguma decincia fsica. A W3C desenvolve padres tambm para que um maiornmero de pessoas possam acessar os contedos na Web 6.

Segundo United Nations (1993), o termo decincia engloba um grande nmero delimitaes, que podem ser fsica, intelectual ou sensorial, condies de sade ou doen-as mentais. Essas limitaes podem ainda ser permanentes ou temporrias. Portanto,enquadram-se nesse termo todas as pessoas que possuem perda ou limitao de oportu-nidades para fazer parte da vida em comunidade de igual forma que os demais. Nessecontexto, pode-se tambm considerar que idosos em sua grande parte esto includos nessacategoria.

Especicamente na rede mundial de computadores, que o foco de estudo desse tra-balho, algumas decincias se tornam obstculos maiores que outras. Segundo Qadri eBanday (2009), a Web Content Accessibility Guidelines (WCAG) W3C (2008), que foi

3http://www.w3.org/Consortium/mission4http://www.w3.org/standards/Webdesign/5http://www.w3.org/standards/Webofdevices/6http://www.w3.org/TR/2008/REC-WCAG20-20081211/

28

http://www.w3.org/Consortium/missionhttp://www.w3.org/standards/Webdesign/http://www.w3.org/standards/Webofdevices/http://www.w3.org/TR/2008/REC-WCAG20-20081211/

desenvolvida com o intuito de denir padres para a acessibilidade na Web, tem comoalvo os seguintes tipos de decincia:

visual: pessoas com decincia visual, incluindo cegos, pessoas com baixa viso oudaltnicos;

auditiva: pessoas com decincia auditiva, com diculdade para ouvir ou completa-mente surdas;

motora: decincia como paralisia cerebral, artrite, mal de Parkinson ou leso nacoluna vertebral que diminuem os movimentos musculares ou o controle desses,fazendo com seja difcil a utilizao de equipamentos como mouse e teclado: os doisequipamentos mais utilizados para navegar na rede mundial de computadores;

cognitiva: a decincia cognitiva inclui baixa memria, limitaes para resolverproblemas, problemas lingusticos incluindo diculdades para leitura e compreensoverbal e problemas de concentrao.

Os padres mais recentes de acessibilidade, segundo W3C (2008), nos instruem a seguirdoze diretrizes divididas em quatro princpios:

perceptvel:

fornecer textos alternativos para contedos no-texto;

fornecer captions e outras alternativas para contedos multimdia;

criar contedo que pode ser apresentado em diferentes formas, incluindo portecnologias assistivas, sem perder o sentido;

facilitar os usurios verem e ouvirem o contedo.

opervel:

fazer todas as funcionalidades estarem disponveis pelo teclado;

dar aos usurios tempo suciente para ler e usar o contedo;

no usar contedo que cause convulses;

ajudar os usurios a navegar e achar contedos.

compreensvel:

fazer o texto legvel e compreensvel;

fazer o contedo aparecer e funcionar de formas previsveis;

ajudar os usurios a evitar e corrigir erros.

robusta:

maximizar compatibilidade com ferramentas atuais e futuras.

Segundo a iniciativa de acessibilidade Web da W3C W3C (2012), em ingls Web Ac-cessibility Initiative WAI, para que essas diretrizes sejam seguidas de maneira correta, essencial que os seguintes componentes sejam considerados:

29

contedo: a informao em uma pgina ou aplicao na Web, incluindo:

informao natural como texto, imagens e sons;

cdigo ou marcao que denem a estrutura, apresentao etc.

navegadores, players de mdia: aplicaes do lado do cliente;

tecnologias assistivas: leitores de tela, teclados alternativos, software de varreduraetc;

usurios: conhecimento, experincia e estratgias adaptativas usando a Web;

desenvolvedores: designers, programadores, autores etc., incluindo desenvolvedorescom decincia e usurios que contribuem com contedo;

ferramentas de autoria: softwares que so utilizados para criar pginas e aplicaespara a Web;

ferramentas de avaliao: ferramentas que avaliam a acessibilidade de pginas, va-lidadores de HTML e CSS etc.

E esses componentes se relacionam, segundo a Figura 2.15, onde pode-se visualizarusurios e desenvolvedores, interagindo com o contedo de formas diferentes: os desen-volvedores criando-os por meio de ferramentas de autoria e de avaliao, enquanto osusurios acessam esses contedos criados por meio de navegadores, players de mdia etecnologias assistivas.

Figura 2.15: componentes para o desenvolvimento de aplicaes acessveis. Fonte: http://www.w3.org/WAI/intro/components.php

Existe uma interdependncia signicativa entre esses componentes, ou seja, eles pre-cisam trabalharem conjunto para que o resultado nal seja acessvel na www. Quandoa acessibilidade est efetivamente implementada em um dos componentes, se torna maissimples desenvolv-la nos demais componentes, como mostrado na Figura 2.16.

30

http://www.w3.org/WAI/intro/components.phphttp://www.w3.org/WAI/intro/components.php

Por outro lado, se a acessibilidade no implementada em um dos componentes, setorna mais difcil desenvolv-la nos demais componentes, como v-se na Figura 2.17. Porexemplo, se a ferramenta de autoria que um desenvolvedor estiver usando no fornecersuporte para acessibilidade, ele ter que utilizar uma forma alternativa, como codicarmanualmente a parte de acessibilidade da sua pgina ou sistema Web. Um outro exemplo o caso do navegador no implementar acessibilidade, o que exigir que o desenvolvedortambm busque caminhos alternativos.

Figura 2.16: ciclo explicitando a interdependncia entre os componentes. Fonte: Henry(2005)

Figura 2.17: grco mostrando a diculdade na implementao da acessibilidade quandoum dos componentes no a implementa. Fonte: Henry (2005)

31

2.3.2 Acessibilidade segundo o programa de governo eletrnico

brasileiro

O governo brasileiro j entende que a acessibilidade na Web obrigao de qualquerinstituio dele, desde 2004, quando foi aprovado o Decreto no 5.296/2004 [Brasil (2004)],que dentre outras instrues, regulamenta o cuidado com a acessibilidade nos stios eportais governamentais.

Em 2005, foi criada a primeira verso do Modelo de Acessibilidade de Governo Eletr-nico (e-MAG), que trata de um conjunto de instrues que devem ser considerados paraa implementao de acessibilidade nos stios e portais do governo de forma padronizadae rpida. Importante notar que o e-MAG possui diversas semelhanas com a primeiraverso das recomendaes denidas pela W3C, WCAG 1.0 7.

Na elaborao do documento foram consideradas as contribuies de especialistas e asnovas pesquisas na rea de acessibilidade na Web, bem como as Recomendaes de Aces-sibilidade para Contedo Web, em ingls Web Content Accessibility Guidelines WCAG[W3C (2008)]. Sempre com foco nas necessidades locais, visando atender s prioridadesbrasileiras.

O e-MAG dene as quatro principais diculdades que as pessoas podem encontrar aoutilizar um computador:

acesso ao computador sem mouse: no caso de decincia visual, onde o mouse no mais til, ou em caso de perda ou paralisia dos membros superiores;

acesso ao computador sem teclado: no caso de amputaes ou grandes limitaesdos movimentos nos membros superiores;

acesso ao computador sem monitor: no caso de pessoas com decincia visual;

acesso ao computador sem udio: no caso de pessoas com decincia auditiva.

Porm, essas no so as nicas diculdades que podem ocorrer ao se usar um compu-tador. Outras diculdades como cognitiva, de memorizao e dislexia tambm devem serconsideradas para a acessibilidade na WWW.

O e-MAG dene o processo para desenvolver um stio acessvel como sendo:

seguir os padres Web;

seguir as diretrizes ou recomendaes de acessibilidade;

realizar a avaliao de acessibilidade.

A parte de seguir os padres Web consiste na necessidade do desenvolvedor seguiros parmetros denidos pela W3C, nas recomendaes de HTML (Hypertext MarkupLanguage), XML (Extensible Markup Language), XHTML (Extensible Hypertext MarkupLanguage) e CSS (Cascading Style Sheets).

A segunda parte, sobre seguir as diretrizes de recomendaes de acessibilidade, tratade adotar os padres internacionais denidos pelo WCAG [W3C (2008)].

A terceira parte do processo trata de avaliar se realmente o sistema est seguindotodos os padres denidos pelos dois passos anteriores.

7http://www.w3.org/TR/WCAG10/

32

Captulo 3

Contexto de Aplicao do MAC

3.1 Estudo de caso

3.1.1 Anlise de possveis estudos de caso

Com o objetivo de escolher um estudo de caso para a realizao das avaliaes, foirealizada uma anlise em diferentes opes de stios que abordam o assunto de realizaode provas de concursos. Os sistemas comparados foram os seguintes: T Na Mo, Meritus,Vestcon, Super Provas, Eu Vou Passar, Questes de Concursos, Rota dos Concursos,dentre outros.

Na Tabela 3.1 so apresentadas informaes comparativas entre os sistemas analisados.Alm da tabela, abaixo tem-se um resumo das funcionalidades desses sistemas:

T Na Mo1: ferramenta gratuita para uso em dispositivos mveis com o sistemaoperacional Android ou IOS. As atualizaes tambm so gratuitas. No possui versopara computador ou para ser utilizada em navegadores da Internet.

Meritus2: stio de apoio ao estudante do curso preparatrio presencial para concursospblicos, situado na cidade de Belo Horizonte MG. Por ser restrito a usurios pagantesdo curso presencial, no foi possvel analisar detalhadamente o contedo desse sistema.

Vestcon3: stio com foco diferente dos demais. uma loja que vende vrios materiaisimpressos e vende tambm o acesso a videoaulas de matrias relacionadas a concursos,resoluo de provas e pacotes voltados ao estudo para concursos especcos.

Superprovas4: ferramenta gratuita para o sistema operacionalWindows, mas que cobraanuidade para o acesso s atualizaes, ou seja, novas questes e simulados. No possuiverso para dispositivos mveis ou para ser utilizada em navegadores Web.

Eu Vou Passar5: stio contendo material de estudo geral voltado para concursos p-blicos, com o diferencial de oferecer um acervo de videoaulas para os alunos que pagammensalidade.

1http://www.tanamaoconcursos.com.br/2http://www.meritus.com.br/3http://www.vestcon.com.br/4http://www.superprovas.com/5http://www.euvoupassar.com.br/

33

Stio Foco Principal Software oine(ComputadorPessoal)

Software oine(DispositivosMveis)

Online Custo Atualizaes

T na mo Aplicativo para estudooine com acesso a umbanco de dados de questes

No Sim (Android,Iphone e IPAD)

No Gratuito Gratuitas

Meritus Apoio ao estudo presencialoferecido

No No No Varivel Variveis

Vestcon Venda de materiais e cursospresenciais / online

No No No Varivel Variveis

Superprovas Aplicativo para estudooine com acesso a umbanco de dados de questes

Sim (Windows) No No Gratuito R$ 60,00/ano

Eu vou passar Videoaulas para ensinar asdisciplinas

No No Sim Gratuitoe pago

R$ 55,00/ms

Questes deConcursos

Simulados e questes paraauxlio ao estudo

No No Sim Gratuitoe pago

R$ 8,90/ms

Rota dosConcursos

Simulados e questes paraauxlio ao estudo

No No Sim Gratuitoe pago

R$ 14,99/ms

Tabela 3.1: comparao entre os principais sistemas de estudo para concursos pblicos citados pelos participantes

34

Questes de Concursos6: ferramenta gratuita que funciona online, podendo ser utili-zada em diversos sistemas operacionais e navegadores de Internet. O foco principal dosistema o estudo focado na resoluo de simulados criados a partir de provas de concur-sos anteriores. Possui duas opes de cadastro: gratuito e pago. H pequenas diferenasentre ambos, a mais evidente o limite de resolver apenas dez questes por dia para osusurios no pagantes.

Rota dos Concursos7: ferramenta gratuita que funciona online, podendo ser utilizadaem diversos sistemas operacionais e navegadores Web. O foco dessa ferramenta o estudopor meio da resoluo de provas e simulados partir de questes de concursos pblicosanteriores. Possui cadastro gratuito e pago, no havendo limite na quantidade de questespor dia para os usurios da verso gratuita.

O fator mais importante para a e