Desenvolvimento da Interface com Foco no Usuário Parte II · Guidelines em Design • Guidelines são muito populares em projeto de interfaces, por constituírem um framework que

1Unidade 03 – Desenvolvimento com Foco no Usuário – Parte II

Interface Homem-máquina

Desenvolvimento da Interface com Foco no

Usuário

Parte II

Instituto Federal de Educação, Ciência e Tecnologia do Triângulo Mineiro

Prof. Edwar Saliba Júnior



GuidelinesGuidelines em em DesignDesign

• 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.



Princípios dos Princípios dos GuidelinesGuidelines

• Falar a língua do usuário;

• Reduzir a carga cognitiva;

• Criar para o erro e

• Manter consistência.



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”.



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?



Reduzir a Carga Cognitiva• A Internet e os diversos softwares e recursos

que são colocados nos computadores pelo usuário, podem vir a ser um vilão contra o próprio usuário;

• Tanto que isto é verdade que existem softwares que prometem ajudar o usuário a manter o foco no trabalho;

• Exemplos:– Conheça 5 Softwares que Evitam as Distrações da Internet

– Link para aula sem Internet.

http://olhardigital.uol.com.br/pro/noticia/37996/37996



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;

• Contraexemplos 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.



Contraexemplo Mensagem de Erro



Contraexemplo Mensagem de Erro



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.



Exemplo de Exemplo de GuidelineGuideline para Formato Consistente para Formato Consistente

Guideline Adotar uma organização consistente para as posições na tela dos vários elementos do sistema

Exemplo 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 Pode ser desejável mudar formatos para distinguir entre tarefas diferentes

Comentário Consistência ajuda na orientação do usuário



Metáforas no Metáforas no Design Design de Interfacesde 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



Metáforas no Metáforas no DesignDesign de Interfaces de Interfaces

“... a good metaphor is essential to an easy-to-use humam interface.”

(Erickson, 1990 apud Rocha e Baranauskas, 2003);



Metáforas no Metáforas no DesignDesign de Interfaces 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, 7 e 8?



Contraexemplo 01Contraexemplo 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.




• 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?




• 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).



Contraexemplo 04• Fora do padrão.

O que há de anormal nestas cenas?

• Vejamos mais perto! (Próximo slide.)



Contraexemplo 04• Que tal simplificar! Não seria melhor colocar a

placa correta uma única vez?

Que placa é esta???



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.



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.



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.



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 às 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.



Modelos de DesenvolvimentoModelos 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 e– Respeitar orçamento e cronograma.

• Parece simples. Não é? Porém, a prática tem mostrado que é muito, muito complexo! Veja o porquê:

– Cada produto é um produto novo;– É dependente do conhecimento;– Para cada problema temos uma solução particular e– 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.



Modelos de DesenvolvimentoModelos de Desenvolvimento

• O processo pode ser divido em:– Desenvolvimento (40% do esforço):

• Início - quando a necessidade do produto é identificada e

• 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%) e

– Correção de erros (20%).

• A manutenção geralmente é cara e inevitável devido às mudanças de requisitos, necessidade de ajustes e aumento de funcionalidades antes não previstas.




• 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 e

– O controle de qualidade é deficiente.

• Como tornar este processo mais eficiente e com menor custo?– Melhorando a qualidade do software produzido e

– 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, organizado, com baixo custo e com qualidade.




• 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 e

– 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, planejamento e etc.);

– Estudar e avaliar métodos, ferramentas e ambientes disponíveis, segundo critérios definidos;

– Educar e treinar e

– Adotar padrões.




• Alguns modelos de Desenvolvimento de Software:– Modelo Tradicional (waterfall ou cascata);

– Modelo Espiral;

– Modelo Eason;

– Modelo Estrela.



Modelo em CascataModelo em Cascata• 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 EspiralModelo em Espiral

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



Modelo de EasonModelo de Eason• Vários modelos para o processo de design têm sido apresentados na literatura de IHM. 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.



Modelo Estrela 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 IHM;

• 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.



Bibliografia• PREECE, Jennifer; ROGERS, Yvonne;

SHARP, Helen. Design de Interação. Porto Alegre, RS: Bookman, 2007.

• ROCHA, M. V. da; BARANAUSKAS, M. C. C. Design e Avaliação de Interfaces Humano-computador. Campinas, SP: NIED/Unicamp, 2003.



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.



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.



O que é isto?

Documents

Desenvolvimento da Interface com Foco no Usuário Parte II · Guidelines em Design • Guidelines são muito populares em projeto de interfaces, por constituírem um framework que