Interacção Pessoa Computador

Apresentação em tema: "Interacção Pessoa Computador"— Transcrição da apresentação:

1 Interacção Pessoa Computador
Licenciatura em Engenharia Informática e Computação Mestrado em Engenharia Informática

2 Projecto de Interacção
‘Projecto’ deve entender-se como desenho. Trata-se de um processo evolutivo. É importante distinguir a interacção “boa” da “má”.

3 Objectivos do Projecto de Interacção
Desenvolver produtos utilizáveis (fáceis de aprender, efectivos e que produzam uma experiência agradável). Envolver os utilizadores durante todo o processo; por vezes o projecto de interacção é chamado de desenho centrado nos utilizadores.

4 O que projectar? Entrar em linha de conta com:
Tipo de utilizador, Tipo de actividade e Contexto de interacção. Optimizar a interacção do utilizador com o produto por forma a igualar as actividades e necessidades do utilizador.

5 O que é IPC? Human-computer interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them. — ACM SIGCHI (2002) Designing interactive products to support people in their everyday and working lives. — Sharp, Rogers and Preece (2002) The design of spaces for human communication and interaction. — Winograd (1997)

6 O que é importante em IPC?
O que é essencial e não se pode aprender por um livro ou CD-ROM? There is only one obvious thing, from which much else follows. Techniques follow once the philosophy is in place. Alan Dix (1998)

7 O que satisfaz os Utilizadores
Gostam de sentir que controlam os objectos. É mais agradável conduzir um automóvel do que viajar num avião. São melhores a reconhecer características do que a relembrar. É mais fácil reconhecer uma pessoa do que recordar o seu nome. É mais fácil memorizar objectos agrupados. 12 maçãs em linhas de 3 ou dispostas ao acaso. (...)

8 O que satisfaz os Utilizadores
É mais fácil aprender fazendo e repetindo. Aprende-se com base na experiência passada e às vezes só quando há mesmo necessidade. O primeiro a chegar ao mercado tem uma grande vantagem pois cria habituação. Todos somos diferentes (a aprender, a comunicar, etc.) e mudamos ao longo do tempo...

9 A vantagem da estruturação visual
Quantos objectos vê? E agora?

10 Mitos – Alan Dix (1998) Os verdadeiros Engenheiros Informáticos não pensam nos utilizadores. “Real CS men don’t think about users.” A Interacção é apenas um detalhe de implementação. O processo e o método são essenciais. Um engenheiro informático tem de usar um método e um processo: SSADM, OMT, UML, RUP, etc. Não é preciso saber programar. Quero fazer um projecto, mas não quero programar (“I want to do a project, but I don’t want any programming”).

11 Tentações Projectar para utilizar bem a tecnologia em vez de projectar para ajudar utilizador e dar-lhe valor. Projectar orientado pela estética (“cool and sexy interfaces”). Norm Cox, que desenhou muitas interfaces incluindo o Xerox Star: “pode-se pôr baton num Buldog, mas isso não significa que se deseja beijá-lo...” Basear o projecto em aspectos lógicos sem considerar o processo de estruturação e gestão visual (auditiva, etc). Considerar que os utilizadores podem introduzir dados certos e errados. Deve ajudar-se o utilizador a fazer o que deseja. (...)

12 Tentações Particularidades e opções em demasia (“featurism”)
Sobrecarregam as linhas de apoio... Problemas com a interface podem ser solucionados com documentação. Podemos corrigir os problemas na próxima versão.

13 Avaliar e Testar Qual a diferença entre Avaliar e Testar?
Paradigmas de Avaliação (Preece et al 2002) Avaliação “rápida e barata” (reuniões informais entre utilizadores e projectistas) Testes de usabilidade (avaliação de desempenho em laboratório) Estudos de campo (entrevistas e grupos de focagem, “focus groups”, com utilizadores e inquéritos para avaliação de satisfação Avaliação preditiva (baseada em heurísticas)

14 Objectivos de Usabilidade
Efectividade Eficiência Segurança Utilidade Aprendizagem Recordação (da forma de funcionamento)

15 Objectivos de Experiência dos Utilizadores
Satisfação Divertimento Beleza estética Motivação Sensação de ajuda

16 Objectivos de Usabilidade e de Experiência dos Utilizadores
Em que é que diferem? Quais são os compromissos entre ambos os tipos de objectivos? Será fácil medi-los?

17 Testando Usabilidade e Satisfação
Testes de Usabilidade: envolve medir o desempenho de utilizadores típicos em tarefas típicas, por exemplo em laboratório, ou obter a avaliação de peritos. Avaliação de desempenho (performance measurement). Avaliação heurística (heuristic evaluation) – ver 10 regras de Nielsen. Avaliação de Satisfação: envolve medir a satisfação subjectiva (ver, por exemplo, WebQual™ em e “Computer enthusiasts may hope that steady improvements in computer usability will result in more positive attitudes towards computers. Littlle is currently known about the relation between attributes of individual computer systems and users’ general attitudes” – [Nielsen 1993] p. 33.

18 Avaliação de Sítios: WebQual™
Qualidade do Sítio Internet Intenção de revisitar Intenção de compra Entretenimento Relação Complementar Capacidade de substituição Facilidade de utilização Tempo de resposta Interactividade Informação Integração da comunicação Relação com o negócio Serviço ao cliente Desenho Utilidade Envolvência Adequação das funções Confiança Visual Inovação Utilização intuitiva

19 Princípios de Desenho (POET [Norman 1983])
Visibilidade: tornar os componentes relevantes bem à vista (ou ao ouvido). Realimentação: o resultado das acções deve ser óbvio e imediatamente observável (e visível de acordo com o princípio anterior). Restrições: físicas, semânticas/lógicas e culturais (ex. LEGO). (...)

20 Princípios de Desenho (POET [Norman 1983])
Mapeamento: a relação entre cada instrumento de controlo e as acções provocadas deve ser óbvia (ex. automóvel, fogão, telefone). Consistência: manter as regras de interacção internamente ao sistema e externamente com o mundo real (ex. teclados, onde guardar objectos). Indicação (possível tradução de affordance): alguns atributos dos objectos reais e das interfaces permitem saber para quê e como devem ser utilizados (ex. puxadores de portas, botões).

21 Calculadoras, Teclados, ...
Consistência Externa Telefones, Comandos, ... Calculadoras, Teclados, ... 1 2 3 4 5 6 7 8 9 7 8 9 1 2 3 4 5 6

22 Exemplos de Indicações (www.joelonsoftware.com [Spolsky 2001])
Muitos sítios Web preferem ter botões «bonitos» em vez de botões que indiquem que podem ser premidos. Como resultado é necessário muitas vezes adivinhar onde clicar. No exemplo os botões “GO” e “LOG ON” sobressaem, indicando que se pode clicar. Os botões “Site Map” e “Help” não aparentam ser tão clicáveis, e, de facto, parecem iguais à etiqueta “QUOTES”, que não é clicável. Há cerca de 5 anos, muitas janelas começaram a mostrar estas ranhuras no canto inferior direito. O sinal indica que se pode puxar. Está mesmo a pedir para “esticar” a janela.

23 Exemplos de Indicações (www.joelonsoftware.com [Spolsky 2001])
Painel de Controlo do Macintosh Painel de Controlo do Macintosh People rarely figured out how to scroll the list to get more than the first 4 control panels. But more critically, most people just didn't understand that there was a connection between the icons and the dialog. The icons actually look like they are one of the choices. Starting in about 1992, these interfaces started to disappear, to be replaced with a new invention called tabbed dialogs.

24 As 10 Heurísticas de Nielsen www.useit.com [2002]
Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. (...)

25 As 10 Heurísticas de Nielsen www.useit.com [2002]
Recognition rather than recall Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

26 Os 3 Princípios de Shneiderman [Shneiderman 1998] www.awl.com/DTUI/
Principle 1: Recognize the Diversity Principle 2: Use the Eight Golden Rules of Interface Design Principle 3: Prevent Errors

27 Shneiderman’s Eight Golden Rules of UI Design
Strive for consistency: Terminology, Prompts, Menus, Help screens, Color, Layout, Capitalization, Fonts, Most frequently violated Enable frequent users to use shortcuts: Abbreviations, Special keys, Hidden commands, Macro facilities Offer informative feedback Design dialogs to yield closure: Sequences of actions should be organized into groups, Beginning, middle, and an end Offer error prevention and simple error handling Permit easy reversal of actions Support internal locus of control Reduce short-term memory load

28 As 10 regras da DECO (Código de Conduta: www.deco.pt)
Segurança jurídica Segurança da empresa e dos produtos Informação dos consumidores Procedimento para a encomenda Direito de retractação (prazo de reflexão) Pagamento Protecção da vida privada Protecção dos menores Segurança nas transacções Ligações com outros sítios Reclamações e regulação dos litígios

29 IPC – Engenharia e Negócio
Retorno do investimento “Uma empresa australiana obteve uma redução de despesas anual de A$ ( €) devido à reengenharia dos seus formulários, ao conseguir diminuir os erros de preenchimento dos seus clientes. O projecto de usabilidade custou menos de A$ ( €). Os formulários iniciais eram tão complicados de preencher que continham uma média de 7,8 erros, obrigando um funcionário a perder mais de uma hora por formulário em actividades de correcção” (citado em [Nielsen 1994]). (...)

30 IPC – Engenharia e Negócio
Empresas Nielsen Norman Group: “help companies enter the age of the consumer, designing human-centered products and services”. Swim: “provides a wide range of design services, in each case targeted to address the product development needs at hand”. IDEO: “creates products, services and environments for companies pioneering new ways to provide value to their customers”. Constantine & Lockwood, Ltd: “supports usage-centered design for more usable software-based products through training, design, evaluation, and consulting services” (

31 O formulário de entrada nos EUA

32 Evolução das IPC 50s – Interfaces ao nível físico para engenheiros: painéis de botões. 60-70s – Interface ao nível da programação: COBOL, FORTRAN (cartões, fitas, etc.). 70-90s – Interface ao nível de linguagem de comandos em terminais ASCII. 80s – Interfaces ao nível de diálogo com o utilizador: IGU e multimédia. 90s – Interface em ambientes de trabalho distribuído: sistemas distribuídos. 00s – Interfaces tornam-se omnipresentes.

33 As palavras da usabilidade...
Objectivos de usabilidade Quanto tempo leva a completar uma tarefa? Objectivos dos utilizadores Como tornar o produto agradável e divertido? Princípios de desenho (antes de fazer) Que tipo de resposta a interface vai dar a uma dada acção do utilizador? Princípios de usabilidade (depois – para avaliar) O sistema tem opções de saída claramente visíveis? Regras de usabilidade Ter sempre um botão de saída numa página Web.

34 Sítios a rever “Convergent Bicycle (Model for Fiancés)” © , Jacques Carelman, ADAGP Paris. Citado em [Norman 1988] p. 13. “Coffepot for Masochists” © , Jacques Carelman, ADAGP Paris. Citado em [Norman 1988] p. 2.

35 Sumário IPC (definição) é ... IPC (história) foi ...
IPC (requer) boa ... Projecto da Usabilidade (arquitectura, engenharia, ...) é ... Atitude do Cliente (satisfação, ...) é ... Interacção: objectivos de usabilidade, objectivos dos utilizadores, princípios de desenho, princípios de usabilidade, e regras de usabilidade.

36 O que ficou na cabeça No final deste capítulo os alunos devem saber:
Descrever e definir IPC Discutir e argumentar sobre a importância da IPC Descrever os objectivos da IPC relacionados com a produtividade e segurança dos sistemas interactivos Descrever a evolução histórica da IPC Quantificar os benefícios da IPC Descrever os componentes da IPC (TPC) Enumerar as disciplinas que contribuem para a IPC (TPC) Reconhecer que são necessários para a IPC um conjunto de valências e conhecimentos Referência: Capítulo 1 [Preece et al 2002]

37 Exercício Prático Estudar uma aplicação, sistema ou sítio Web.
Definir lista de tarefas possíveis a serem testadas (escrever as tarefas sem ter a aplicação à vista; ordenar por dificuldade). Pedir aos utilizadores para executarem as tarefas propostas, observando o que fazem. Avaliar as reacções dos utilizadores e procurar com a sua ajuda desenhar a nova interacção. Como obter informação dos utilizadores? Quando é este «método» aplicável?

38 Bibliografia [Preece et al 2002] Jenny Preece, Yvonne Rogers, Helen Sharp: «Interaction Design» [Constantine 2001] Larry Constantine: «The Peopleware Papers: Notes on the Human Side of Software» [Nielsen 1999] Jakob Nielsen: «Designing Web Usability» [Norman 1999] Donald A. Norman: «The Invisible Computer» [Roberts et al 1998] Dave Roberts, Dick Berry, Scott Isensee, John Mullaly: «Designing for the User with OVID: Bridging User Interface Design and Software Engineering» www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/558 [Shneiderman 1998] Ben Shneiderman: «Designing the User Interface: Strategies for Effective Strategies for Effective Human-Computer Interaction» [Tufte 1992], [Tufte 1993], [Tufte 1997] Edward Rolf Tufte: «Envisioning Information», «The Visual Display of Quantitative Information» (2nd Ed.), «Visual Explanations»