Desenvolvimento da Interface com Foco no Usuário. Parte II

Transcrição

1 Desenvolvimento da Interface com Foco no Usuário Parte II Instituto Federal de Educação, Ciência e Tecnologia do Triângulo Mineiro Agosto de 2012 Prof. Edwar Saliba Júnior 1

2 Guidelines em Design Guidelines são muito populares em projeto de interfaces, por constituírem um framework que orienta o designer na tomada de decisões consistentes, através dos elementos que constituem o produto; Possuem formas variadas: artigos acadêmicos, manuais, estilos associados a marcas e etc. Devem ser entendidos e aplicados de forma contextualizada; O uso de guidelines não deve ser entendido como receita de design, mas sim como um conjunto de princípios norteadores do design. 2

3 Princípios dos Guidelines Falar a língua do usuário; Reduzir a carga cognitiva; Criar para o erro; Manter consistência. 3

4 Falar a Língua do Usuário Língua deve ser entendida de forma ampla, no contexto sócio cultural estabelecido da população de usuários; Envolve conhecer essa população, estar atento para as diferentes necessidades do usuário, promover sua satisfação pessoal e permitir que ampliem e facilitem a realização de suas tarefas; Uma interface que fale a língua do usuário ajuda-o a atravessar o golfo de execução e interagir com o sistema; Exemplo: num editor de textos para crianças, havia como opção de menu para escolha do tipo de letra, o termo cursiva. Certamente essa não é uma palavra do vocabulário infantil os usuários finais do sistema eram crianças em processo de alfabetização que conhecem as letras de forma e letras de mão. 4

5 Reduzir a Carga Cognitiva Isso significa que o usuário não deve ter que se lembrar de grande quantidade de informação para usar bem o sistema; Sobrecarregar a memória do usuário significa exigir maior processamento cognitivo para atividades de uso do sistema nem sempre relevantes à tarefa propriamente dita; Quantas vezes, ao navegar pela Internet, você se esqueceu do que estava buscando inicialmente? 5

6 Criar Para o Erro Pressupõe a observação geral sobre design de que mesmo que se tenha feito o melhor sistema possível, usuários tanto os novatos quanto os experientes cometerão erros ao usá-lo; O design que considera a condição humana do erro deve forçar ações que previnam ou dificultem o erro do usuário; Prover ações reversíveis ajuda a minimizar a ansiedade e o medo do novato de destruir alguma coisa ; Mensagens de erro efetivas e feedback ajudam o usuário a saber o que fazer quando o resultado de suas ações não produz o que ele espera; Um bom exemplo de aplicação desta guideline é a possibilidade de desfazer operações (undo) e repetir operações (redo) presentes em algumas interfaces; Um contraexemplo bastante simples são mensagens de aplicativos que, ao invés de esclarecerem o porquê do acontecimento do erro, mostram apenas um código qualquer. 6

7 Contraexemplo Mensagem de Erro 7

8 Manter Consistência Consistência emerge do uso de padrões, que são mantidos ao longo do design de todos os componentes que constituem o produto; Consistência também é derivada do uso apropriado de metáforas, que ajudam o usuário a construir e manter um modelo mental apropriado do sistema idealmente coincidindo com o modelo mental do próprio designer. 8

9 Exemplo de Guideline para Formato Consistente Guideline Exemplo Adotar uma organização consistente para as posições na tela, dos vários elementos do sistema Posição para o título Área para dados de saída Área para opções de controle Área para instruções Área para mensagens de erro Área para entrada de comando Exceção Comentário Pode ser desejável mudar formatos para distinguir entre tarefas diferentes Consistência ajuda na orientação do usuário 9

10 Metáforas no Design de Interfaces O que são metáforas? Sentido figurado, imagem, figura. Metáforas nos ajudam a construir Modelos Mentais sobre o artefato com o qual interagimos; Os sistemas estão cheios de exemplos metafóricos, como: Objetos, pincéis, lápis de desenho, assistentes e etc. Exemplo: Copiar e Colar Recortar e Colar 10

11 Metáforas no Design de Interfaces... a good metaphor is essential to an easy-to-use humam interface. (Erickson, 1990 apud Rocha e Baranauskas, 2003); 11

12 Metáforas no Design de Interfaces A lixeira é uma ótima metáfora: Pra que serve a lixeira? O que representa o símbolo desenhado na lixeira do Windows XP, Vista e 7? 12

13 Contraexemplo 01 Uma metáfora na interface que sugira um Modelo Mental incorreto causa dificuldades ao usuário; Há alguns anos, no Macintosh, a metáfora da lixeira foi estendida para incluir uma nova função: O eject do disquete; O arraste do disquete para a lixeira para retirálo do computador, era incompatível com o modelo mental do usuário e causava problemas conceituais a este, que tinha medo de ter o conteúdo do disquete apagado. 13

14 Contraexemplo 02 A imagem ao lado mostra a caixa de diálogo da impressora Mannesman Tally (Shame, 1999 apud Rocha e Baranauskas, 2003, p. 127), que utiliza a metáfora do VCR para controlar a impressora; Uma pergunta básica: Na tarefa de impressão de um documento, que associação o designer esperaria que o usuário fizesse com o botão de Rewind? 14

15 Contraexemplo 03 Read-Please2000 (Shame, 1999 apud Rocha e Baranauskas, 2003, p. 127). Uma aplicação útil para a tradução de texto para fala, em que não é clara a associação que deva ser feita com um Palm Pilot (Palm Top ou Pocket PC). 15

16 Guidelines para Design Baseado em Metáforas Madsen (1994) apud Rocha e Baranauskas (2003) propõe uma série de guidelines para o design baseado em metáforas; Para tal são identificadas três diferentes atividades: Fase (1) Geração de Metáforas; Fase (2) Avaliação de Metáforas Candidatas ao Design; Fase (3) Desenvolvimento do Sistema Propriamente Dito. Vamos detalhar as três fases nos próximos slides. 16

17 Fase (1) Guideline para Geração de Metáforas Observar como os usuários entendem seus sistemas computacionais; Construir sobre metáforas já existentes; Usar artefatos predecessores como metáforas; Notar metáforas já implícitas na descrição do problema; Procurar eventos do mundo real que exibam aspectos chave. 17

18 Fase (2) Guideline para Avaliação de Metáforas Candidatas ao Design Escolher uma metáfora com uma estrutura rica; Avaliar a aplicabilidade da estrutura; Escolher uma metáfora adequada à audiência (usuários do sistema); Escolher metáforas com significado literal bem entendido; Ter pelo menos um conceito como ponte entre o significado literal e o metafórico; Não necessariamente incorporar a metáfora no design final. Avaliação e verificação de usuários, culturas, costumes e outros; são necessárias para que a metáfora não represente algo inadequado para os usuários e/ou os locais onde o sistema será utilizado. 18

19 Fase (3) Guideline para Desenvolvimento do Sistema Propriamente Dito Elaborar metáfora com o conceito principal, o conceito central do sistema; Procurar novos significados para o conceito. Desenvolvendo novas metáforas que possam substituir as existentes, desde que, esta nova metáfora seja melhor que a anterior; Reestruturar a nova percepção da realidade. Adequando as metáforas à evolução do sistema; Dar maior ênfase as metáforas que melhor representam o sistema e suas diversas áreas; Identificar as metáforas não usadas; Discutir com os envolvidos com o software, a respeito das opiniões de cada um sobre as metáforas que serão utilizadas. 19

20 Modelos de Desenvolvimento Tudo começou, se é que podemos falar em começo, com a chamada Crise do Software. Mas afinal que crise é esta e por que ela existe? Afinal desenvolver software é tão complexo e difícil assim? Existem alguns itens básicos que devem ser levados em consideração no desenvolvimento de software, são eles: Atender requisitos e satisfazer usuários; Respeitar orçamento e cronograma. Parece simples. Não é? A prática tem mostrado que é muito, muito complexo: Cada produto é um produto novo; É dependente do conhecimento; Para cada problema temos uma solução particular; Software não é construído a partir de partes pré-existentes. Geralmente o software produzido é de baixa qualidade e os processos envolvidos são de baixa eficácia e produtividade. 20

21 Modelos de Desenvolvimento O processo pode ser divido em: Desenvolvimento (40% do esforço): Inicio - quando a necessidade do produto é identificada; Fim - quando os testes do produto implantado são concluídos e o produto é entregue para produção. Manunteção (60 % do esforço). Todas as atividades após a entrega: Aumento da capacidade do produto (60%); Adaptação do produto a novos ambientes (20%); Correção de erros (20%). A manutenção geralmente é cara e inevitável devido as mudanças de requisitos, necessidade de ajustes e aumento de funcionalidades antes não previstas. 21

22 Modelos de Desenvolvimento Por que o custo é tão alto? Não há controles sobre prazos ou planejamento sobre equipes e recursos; O levantamento de requisitos não é feito de forma integrada com o cliente e dentro de padrões definidos; O controle de qualidade é deficiente. Como tornar este processo mais eficiente e com menor custo? Melhorando a qualidade do software produzido; Melhorando o processo de produção do software. Surgiu então a Engenharia de Software com a proposta de utilização de princípios de engenharia para atividades de projeto e construção de software a fim de obter um software eficiente. 22

23 Modelos de Desenvolvimento A Engenharia de Software deve usar a prática para sistematizar as atividades de: Entender claramente o problema que se quer resolver; Desenvolver ferramentas e técnicas para resolvê-lo; Gerenciamento de equipes para resolver o problema. Como promover a Engenharia de Software? Explicar a necessidade e demonstrar benefícios; Desenvolver planos realísticos para introduzi-la no desenvolvimento (cronograma, etc.); Estudar e avaliar métodos/ferramentas/ambientes disponíveis segundos critérios definidos; Educar e treinar; Adotar padrões. 23

24 Modelos de Desenvolvimento Principais modelos de Desenvolvimento de Software: Modelo Tradicional (waterfall ou cascata); Modelo Espiral; Modelo Eason; Modelo Estrela. 24

25 Boehm (1995) apud Rocha e Baranauskas (2003), caracteriza bem a visão tradicional da Engenharia de Software para o desenvolvimento de software, como um conjunto de processos e representações produzidas de maneira linear; O principal problema com o modelo cascata é que é impossível entender completamente e expressar os requisitos do usuário antes que algum design tenha sido feito. Além disto, as possibilidades de mudanças no software a partir da etapa de manutenção são mínimas, em função dos comprometimentos e custos envolvidos ao longo da cadeia; Modelo em Cascata 25

26 Modelo em Espiral Em resposta aos problemas do modelo cascata, Boehm (1995) apud Rocha e Baranauskas (2003), propõe o modelo espiral. 26

27 Modelo de Eason Vários modelos para o processo de design têm sido apresentados na literatura de IHC. Entre eles destaca-se o modelo de Eason apud Rocha e Baranauskas (2003). Nesse modelo, o processo de design é representado como um processo de natureza cíclica centrado em pessoas, trabalho e tecnologia e é ordenado e não ad-hoc. 27

28 Modelo Estrela O modelo estrela (Hix e Hartson, 1993), derivado de extensa análise da prática corrente de design à época, é bastante popular entre a comunidade de IHC; Esse modelo, apresenta uma abordagem ao desenvolvimento como ondas alternantes. As atividades são similares às do modelo em cascata, mas a avaliação é central e o início do processo pode acontecer em qualquer uma das demais atividades. 28

29 Bibliografia PREECE, Jennifer; ROGERS, Yvonne; SHARP, Helen. Design de Interação. Porto Alegre, RS: Bookman, ROCHA, M. V. da; BARANAUSKAS, M. C. C. Design e Avaliação de Interfaces Humanocomputador. Campinas, SP: NIED/Unicamp,

30 Ad hoc A expressão latina ad hoc significa literalmente para isto, por exemplo, um instrumento ad hoc é uma ferramenta elaborada especificamente para uma determinada ocasião ou situação ("cada caso é um caso"). Num senso amplo, poder-se-ia traduzir ad hoc como específico ou especificamente; Algo feito ad hoc ocorre ou é feito somente quando a situação assim o exige ou o torna desejável ao invés de ser planejado e preparado antecipadamente ou fazer parte de um plano mais geral; Um processo ad hoc consiste em um processo em que nenhuma técnica reconhecida é empregada e/ou cujas fases variam em cada aplicação do processo. 30

31 Crise do Software Termo utilizado nos anos 70, quando a Engenharia de Software era praticamente inexistente; O termo expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda; Representava também a complexidade dos problemas a serem resolvidos e a inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados. 31