SENAI - Aula3.ppt [Modo de Compatibilidade] - Heuber Lima · consequentemente, apresentam diversos...

Projeto de Interface

Prototipação

Projeto de Interface Homem-Máquina

Prof. Esp. MBA Heuber G. F. Lima

� http://magelstudio.com.br/tag/arquitetura-de-informacao/

� http://uxp.com.br/tag/iphone

Page � 2

� Revisão dos Critérios de Ouro

� Definição de Protótipos

� Características

� Exemplos

� Exercícios em Laboratório

Agenda

Page � 3

� Exercícios em Laboratório

Regras de ouro no desenvolvimento de interfaces

�Busca de consistência

�Permitir uso de atalhos para experientes

�Oferecer feedback informativo

�Organização dos diálogos de interação

Page � 4

�Organização dos diálogos de interação

�Prover prevenção de erros e fácil tratamento

�Prover fácil reversão das ações

�Suportar controle local das ações

�Reduzir a demanda por memorização“Para o usuário, a interface é o sistema”


�Consistência: este item cobre aspectos relativos desde terminologia empregada, passando por seqüências de ações executadas em situações semelhantes, até detalhes como cores, fontes e menus;

Page � 5

menus;

�Atalhos para usuários experientes: a disponibilização de teclas de atalho ou de outras formas de acelerar o processo de interação é muito importante para tornar o sistema mais produtivo a usuários experientes;


�Feedback informativo: é essencial que o usuário saiba o que está acontecendo com o sistema para ter segurança sobre a execução das tarefas requisitadas;

�Organização dos diálogos de interação: as

Page � 6

�Organização dos diálogos de interação: as seqüências de ações para desempenhar uma determinada tarefa devem ser organizadas em grupos com início e fim bem definidos, a fim de deixar claro ao usuário o que deve ser feito para executar algo e quando uma tarefa está concluída;


�Prevenção de erros de usuários: Todos os esforços devem ser empenhados no sentido de prevenir a maior quantidade de falhas possível.

�Reversibilidade de ações: Devem ser oferecidos recursos para corrigir erros durante a execução do

Page � 7

recursos para corrigir erros durante a execução do sistema, como o comando de desfazer ações anteriores. Prover boas mensagens de erros e possuir recursos de ajuda on-line para facilitar a busca de soluções em situações confusas são expedientes que também facilitam bastante a vida dos usuários;


�Controle do usuário sobre o sistema: sendo o usuário o elemento racional da relação homem-computador, ele deve se sentir com o controle da situação em que está envolvido com o sistema;

�Redução da necessidade de memorização: o usuário deve

Page � 8Interface Humano Máquina

�Redução da necessidade de memorização: o usuário deve precisar memorizar o mínimo de informações possível sobre a interação com o sistema. Para tanto, na medida do possível, comandos devem ser substituídos por opções de menu, números de objetos por nomes, dentre outros, além de ser essencial o acesso do usuário à documentação do sistema para esclarecer eventuais dúvidas.

ControlesControles

�Controles que permitem ao usuário executar ações programadas no sistema;

�O grupo de botões de comando deve ser definido nas situações em que as opções de comandos possíveis forem em número reduzido.

– Seu arranjo pode seguir duas regras:

Botões de comando

Page � 10

– Seu arranjo pode seguir duas regras:

• Eles podem ser alinhados verticalmente e a direita do objeto a que fazem referência, ou

• Horizontalmente e abaixo deste objeto.

– Um botão "por default" deve ser definido, visualmente diferenciado e posicionado:

• Ao alto, se a orientação for vertical, ou

• A esquerda, no caso de uma orientação horizontal.

Botões de rádio

�Controles utilizados para a entrada de dados deve prever botões de rádio (radio-button), quando:

– O conjunto de valores possíveis para um dado forem conhecidos;

– Não excederem 7 alternativas; e

– Forem mutuamente exclusivos.

Page � 11


Caixas de atribuição

�Se os valores possíveis para uma entrada não forem mutuamente exclusivos, estando envolvidos em uma escolha múltipla, deve-se prever um grupo de caixas de atribuição (check-box).

Page � 12

�O layout de um grupo de caixas de atribuição (check-box) está sujeito às mesmas recomendações propostas para um grupo de botões de rádio.

Caixa de Combinação

� Combo-box: É a combinação de uma caixa de texto com uma lista de dados. É usada quando:

– O conjunto de valores possíveis para um dado forem conhecidos;

– Excedem sete alternativas; e


Page � 13

Campo de dados

� Um campo de dado é por definição unilinear. Eles recebem dados cujos valores não podem de ante mão, ser previstos pelo projetista e cujos comprimentos não excedam os 40 ou 50 caracteres.

� Todo o campo de dado deve apresentar

Page � 14

� Todo o campo de dado deve apresentar um rótulo identificativo e convidativo (prompt), para apoiar o usuário na entrada de um dado.

� Isso pode ser feito através da explicitação do formato (dd/mm/aaaa) do dado, de sua unidade (cm, pol) e dos valores possíveis (1 a 10).

Projetando um campo de dados

� Com o objetivo de minimizar as ações do usuário o projetista pode especificar um valor a ser proposto "por default" ao usuário.

� Na escolha de um modo de edição, "inserir entre" deve ter a preferência sobre o modo "escrever sobre".

� Nesse particular, seja qual for a definição ela deve ser mantida consistente durante o projeto da interface.

Page � 15

consistente durante o projeto da interface.

� Os métodos para o tratamento dos valores entrados podem considerar equivalentes as letras maiúsculas e minúsculas.

� O preenchimento dos zeros e dos pontos decimais desprezados pelo usuário também deve ser considerado.

Campo de texto

� O campo de texto é por definição multilinear.

� Seu tamanho em termos do número e do comprimento de linhas deve ser adequado para proporcionar um desempenho eficiente na tarefa de entrada de textos.

� Para a facilidade de leitura o comprimento das linhas não deve exceder os 40 caracteres e a altura do campo deve proporcionar a apresentação de um mínimo de 4 linhas.

Page � 16

de um mínimo de 4 linhas.

Prototipação

Prototipação - Conceitos

� É uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo.

� Esta abordagem envolve a produção de versões iniciais - protótipos (análogo a maquetes para a arquitetura) - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído.

Page � 18


�Um protótipo é um sistema de demonstração que se apresenta aos usuários e Stakeholders de forma a validar os requisitos conhecidos ou obtê-los quando os requisitos conhecidos são vagos ou indefinidos.

�Um protótipo pode ser usado como meio de comunicação entre os diversos membros da equipe de

Page � 19

comunicação entre os diversos membros da equipe de desenvolvimento ou mesmo como meio de nós mesmos testarmos a nossas idéias (Sommerville, Sawyer 1997).

�Os Stakeholders são as pessoas ou organizações que são de alguma forma afetadas pelo sistema e/ou que tem diretamente ou indiretamente influência nos requisitos do sistema.


�Um outro motivo para recorrer a prototipação é que geralmente os Stakeholders não conseguem especificar o que pretendem, mas perante um sistema e após uma breve utilização, facilmente especificam o que não pretendem.

Page � 20

�A experiência permite concluir que o sistema final será tanto melhor quanto mais iterativo for o processo de desenvolvimento do protótipo (Rogers, Sharp, Preece, 2002). �Os protótipos podem ser desenvolvidos usando tecnologias que em nada se assemelham com as do sistema final (Kotonya, Sommerville 1998).


�Os protótipos podem ser elaborados recorrendo a diversas técnicas, materiais e consequentemente, apresentam diversos custos (Rogers, Sharp,Preece 2002). �Podem ser um conjunto de folhas de papel com as interfaces do sistema desenhadas, elaboradas

Page � 21

as interfaces do sistema desenhadas, elaboradas em alguma aplicação de efetuar apresentações, maquetes a 3 dimensões, um pedaço de software, um vídeo em que se simula uma tarefa, entre muitas outras possibilidades. �A prototipação tem sempre como fim permitir aos usuários interagirem com a visão do sistema final.

Prototipação - Problemas

�O tempo de desenvolvimento de protótipos está dependente da experiência das pessoas envolvidas. O tempo dos protótipos iniciais pode ser demorado, enquanto se adquire a experiência de como elaborar protótipos de forma rápida e eficiente (Kotonya, Sommerville 1998). �Em algumas circunstâncias o desenvolvimento de

Page � 22

�Em algumas circunstâncias o desenvolvimento de protótipos atrasa o desenvolvimento e origina um aumento do custo do sistema final. O sistema obtido com base nos resultados da elaboração dos protótipos é melhor mas poderá não ser recompensador (Kotonya, Sommerville 1998). �Alguns requisitos, como requisitos de “em tempo real” e

requisitos não funcionais podem ser difíceis ou mesmo impossíveis de implementar num protótipo (Sommerville, Sawyer 1997) (Kotonya, Sommerville 1998).

Prototipação - Implementação

� Desde o inicio do desenvolvimento do protótipo, deve estar bem definido quais são os objetivos a serem atingidos com o desenvolvimento do protótipo.

� Os usuários que experimentarem o protótipo devem saber claramente com são os objetivos do protótipo de forma a não haver falsas expectativas e levar a fracasso da experiência.

Page � 23

Prototipação - Implementação

�Após termos definido os objetivos, temos de decidir quais os requisitos a implementar no protótipo.

�É necessário nesta fase estabelecer um compromisso entre os requisitos a implementar e os que não serão implementados.

�Dependendo do tipo de prototipagem adotada,

Page � 24

�Dependendo do tipo de prototipagem adotada, prototipagem de baixa fidelidade ou alta fidelidade, diferentes compromissos serão necessários estabelecer.

�O tempo de desenvolvimento do protótipo é essencial que seja o mais curto possível.

– O rápido desenvolvimento do protótipo permitirá que os utilizadores experimentem o protótipo na fase inicial do desenvolvimento, minimizando os custos associados as alterações nos requisitos.

Protótipos - Classificação

�Protótipos de Baixa Fidelidade: são aqueles que não se assemelham com o produto final (Rogers, Sharp, Preece 2002).

– São úteis para a exploração e testes na fase inicial de desenvolvimento do sistema.

Page � 25

desenvolvimento do sistema.

– São simples, baratos e de fácil produção e alteração facilitando deste modo a exploração e teste de idéias.

– Estes tipos de protótipos nunca são desenvolvidos com o objetivo de serem incorporados no produto final.

Protótipos de Baixa Fidelidade:

�Aspectos positivos:– Custos Reduzidos; – Menor tempo de desenvolvimento; – Eficiente para recolha de requisitos de interface; – Eficiente e facilita múltiplos testes de opções de design.

�Aspectos negativos:


�Aspectos negativos:– Reduzida utilidade após a definição do documento de

requisitos (ex: na fase de testes do sistema final); – Definição incompleta (ou limitada) do esquema de

navegação; – Verificação limitada de erros;– Especificação pobre para codificação;– Utilidade limitada para testes de usabilidade.

Protótipos - Classificação

�Protótipos de Alta Fidelidade: Os protótipos de alta fidelidade são aqueles que mais se assemelham com o produto final (Rogers, Sharp, Preece 2002).

– Utilizam as mesmas técnicas e materiais que o sistema


– Utilizam as mesmas técnicas e materiais que o sistema final (Rogers, Sharp, Preece 2002).

– São os protótipos indicados quando os objetos são a venda do sistema ou o teste de problemas técnicos.

– O protótipo ainda deve ter funcionalidades limitadas e os requisitos não funcionais, normalmente, não estão implementados.

Protótipos de Alta Fidelidade:

� Aspectos positivos:

– Possuir funcionalidades semelhantes às do sistema final;

– Permitir a definição completa do esquema de navegação;

– Permitir elevado grau de interatividade com os utilizadores;

– Permitir a exploração e testes diversos com um elevado grau de realismo;

– O Protótipo é um documento de requisitos;

Page � 28

– O Protótipo é um documento de requisitos;

– Facilita a venda da idéia do sistema final;

� Aspectos negativos:

– Custos maiores de desenvolvimento;

– Elevado tempo de desenvolvimento;

– Pode aumentar demais as expectativas dos usuários;

– Não serve para coleta de requisitos, pois os mesmos já estão incluídos no protótipo.

Comparando os protótipos

Tipo Vantagens Desvantagens

Baixa-

Fidelidade

•Custos mais Baixos

•Vários conceitos de design

•Problemas de layout de tela

•Identificar requisitos de mercado

•Prova de conceito

•Verificação de erros limitada

•Especificação de código fraca

•Conduzido pelo facilitador

•Utilidade limitada depois da fase de

requisitos

•Pouco útil para testes de usabilidade


•Pouco útil para testes de usabilidade

•Limitações de fluxo e navegacionais

Alta-fidelidade •Funcionalidade Completa

•Interactivo Completamente

•Conduzido pelo usuário

•Esquema navegacional

•Exploração e Teste

•Look “Produto acabado”

•Especificação “viva”

•Ferramenta de vendas e marketing

•Mais caro para desenvolver

•Consome muito tempo na criação

•Ineficiente para provas de conceito

•Ineficaz para aquisição de requisitos

Tipos de Protótipos

�Protótipos em papel: é desenvolvido um conjunto de interfaces associadas a cenários de utilização que são apresentados aos usuários.– Este tipo de prototipação é barata e eficiente (Rogers, Sharp,

Preece, 2002)(Kotonya, Sommerville 1998).

– É mais indicada quando o sistema a desenvolver é software. Não é

Page � 30

– É mais indicada quando o sistema a desenvolver é software. Não é necessário desenvolver software executável.

– Os analistas e usuários percorrem estes cenários, simulando a utilização do sistema, sendo analisado as reações dos utilizadores, a informação requerida e a forma de interação com o sistema.

– Este método é muito eficiente para sistemas interativos, sendo considerado como protótipo de baixa fidelidade (Rogers, Sharp, Preece, 2002).

Page � 31

Page � 32


�Protótipo “Wizard of Oz”: uma pessoa simula as respostas dos sistemas em resposta as ações dos usuários.– Este tipo de prototipagem é relativamente barata visto apenas a

interface do sistema ter de ser desenvolvida (Kotonya, Sommerville 1998).

Page � 33

1998).

– Os usuários interagem com o que parece ser o sistema em que as suas ações são analisadas por um pessoa que simula a resposta do sistema.

– É particularmente útil quando o sistema a desenvolver tem por base numa interface existente.

– Este tipo de protótipo é de baixa fidelidade (Rogers, Sharp, Preece, 2002).


�Protótipo automático: é utilizado linguagens de programação 4GL ou outras linguagens que permitem um rápido desenvolvimento de protótipos executáveis, podendo ser utilizadas IDE´s.

Page � 34

– Este tipo de prototipagem é a mais cara (Kotonya, Sommerville 1998).

– Envolve o desenvolvimento de software, recorrendo a linguagens de programação de alto nível, que simule as funcionalidades do sistema.

– O problema principal do desenvolvimento de protótipos executáveis é de os usuários não simularem a real utilização do sistema final devido ao fato de muitos dos requisitos não funcionais do sistema não estarem provavelmente implementados em conjunção com falta de treino.

Page � 35

Critérios Ergonômicos

Exercícios em Sala de AulaExercícios em Sala de Aula

Page � 36

Exercícios em Sala de AulaExercícios em Sala de Aula

Exercício 2

� A clínica odontológica “WebDental ” precisa de um sistema que controle os seus clientes, o odontograma dos pacientes e agenda dos dentistas

– Na Ficha dos pacientes os campos a serem gravados no sistema são: o nome completo, o endereço completo, a filiação do paciente e os telefones para contato.

– No Odontograma o dentista deverá marcar para cada dente o

Page � 37

– No Odontograma o dentista deverá marcar para cada dente o tratamento a ser feito. Para cada dente poderá ser feito vários tratamentos e os tratamentos poderão ser feitos em datas diferentes. O sistema deverá armazenar o histórico dos tratamentos do paciente. O dentista poderá imprimir o odontograma.

– Na Agenda o dentista deverá controlar o agendamento dos seus atendimentos bem como planejar o tratamento para a sessão.

Exercício 3

� O objetivo é construir um sistema de vendas web par a a loja Bikenet – Sistema de vendas de bicicletas via web.

� Deverão existir no, mínimo, 4 páginas:

– 1 de entrada no site, indicando sua utilidade;

– 1 de pesquisas, por utilidade, modelo, tipo etc.;

– 1 de cadastro dos compradores e informações de paga mento; e

– 1 de gráficos de desempenho dos produtos, a serem d efinidos mais tarde.

Page � 38

– 1 de gráficos de desempenho dos produtos, a serem d efinidos mais tarde.

� No projeto da página para venda de bicicletas, deve rão existir os seguintes tipos de objetos de interação:

– Botões de comando, por exemplo: para mudança de pág inas;

– Caixas de atribuição, por exemplo: para seleção de tipos diferentes de acessórios;

– Campos de dados, por exemplo: para preencher com os dados do comprador (nome, endereço, forma de pagamento) e da bicicleta escolhida (dimensões, modelo, cor); e

– Barras de rolagem, por exemplo: em caso de comentár ios sobre o desempenho da bicicleta.

[email protected]

Obrigado!Obrigado!

SENAI - Aula3.ppt [Modo de Compatibilidade] - Heuber Lima · consequentemente, apresentam diversos...

Documents

Transcript of SENAI - Aula3.ppt [Modo de Compatibilidade] - Heuber Lima · consequentemente, apresentam diversos...