Orientações para o desenvolvimento do framework para utilização nos debates de norma e mérito das pesquisas oriundas do projeto Pensando o Direito

Share Embed


Descrição do Produto

Ministério da Justiça SECRETARIA DE ASSUNTOS LEGISLATIVOS - SAL PROGRAMA DAS NAÇÕES UNIDAS PARA O DESENVOLVIMENTO - PNUD

Projeto Pensando o Direito – SAL / PNUD PRODOC BRA/07/004 Consultoria PNUD – Produtos Previstos

Produto 03 Manual de User experience/User interface Guidelines - Orientações para o desenvolvimento do framework para utilização nos debates de norma e mérito das pesquisas oriundas do projeto Pensando o Direito

Brasília, 07 de fevereiro de 2011

À SECRETARIA DE ASSUNTOS LEGISLATIVOS Dr. Marivaldo de Castro Pereira Secretário de Assuntos Legislativos do Ministério da Justiça Tel.: 61 2025-3114 e-mail: [email protected]

Ref. Manual de User experience/User interface Guidelines - Orientações para o desenvolvimento do framework para utilização nos debates de norma e mérito das pesquisas oriundas do projeto Pensando o Direito

Em consonância com os objetivos e Cronograma previsto no âmbito do projeto BRA/07/004: Democratização de Informações no Processo de Elaboração Normativa, firmado entre o Programa das Nações Unidas para o Desenvolvimento (PNUD) e a Secretaria de Assuntos Legislativos do Ministério da Justiça (SAL), a consultora abaixo subscrita vem, por meio deste, apresentar o Manual de User experience/User interface Guidelines - Orientações para o desenvolvimento do framework para utilização nos debates de norma e mérito das pesquisas oriundas do projeto Pensando o Direito, configurado como produto 3 da consultoria técnica em Design de Interfaces para especificação e desenvolvimento de sites no âmbito do Projeto Pensando o Direito da SAL. O presente relatório deve priorizar as metodologias de desenvolvimento no âmbito do projeto, como forma de traçar melhores práticas para o ambiente em questão.

Atenciosamente, Yasodara Maria Damo Córdova Consultora PNUD - técnica Design de Interfaces para especificação e desenvolvimento de sites no âmbito do Projeto Pensando o Direito da SAL

1. Apresentação Este relatório é parte da consultoria para o projeto Pensando o Direito (BRA/07/004) que tem como objetivo possibilitar que publicações relativas ao projeto Pensando o Direito se tornem parte de um acervo público na rede, para que os produtos das pesquisas acadêmicas possam ser discutidos e expostos na web, tanto para difundir e qualificar o trabalho da Secretaria de Assuntos Legislativos, quanto para incentivar e possibilitar o debate entre cidadãos e as instituições, bem como fomentar a participação pública na construção legislativa. O presente relatório visa orientar as metodologias de desenvolvimento de aplicativos para o portal do Pensando o Direito de modo a conseguir agilidade, flexibilidade, modularidade e reaproveitamento de código (e de recursos, por consequência) no âmbito do Ministério da Justiça. Do mesmo modo, este documento busca direcionar e esclarecer sobre as principais ferramentas para estabelecimento de padrões em design para conseguir consistência em todos os sistemas, traçando guidelines que possam aglutinar as interfaces relacionadas ao projeto e os elementos que as compõem em sistemas que façam sentido para os usuários, conseguindo assim maior participação dos usuários e um debate proveitoso entre indivíduos e a Secretaria de Assuntos Legislativos. O trabalho do consultor visa facilitar este processo documentando tudo para posterior internalização dessa tecnologia na infraestrutura de Tecnologia da Informação do Ministério da Justiça. Atendendo-se aos requisitos da arquitetura e-PING - Padrões de Interoperabilidade de Governo Eletrônico, publicada pelo Ministério do Planejamento, Orçamento e Gestão, o desenvolvimento deve observar a adoção preferencial de padrões abertos e a priorização do uso de software público e/ou software livre.

2. Introdução Design é diálogo em imagens. Enquanto a leitura1 demanda que o cérebro processe a informação em mais fases – reconhecer e reunir símbolos para depois rotular e construir significados – o design transforma significados em imagens para serem absorvidos de maneira

1 A History of Reading. MANGUEL, Albert (1996). London, Harper Collins, 47-8

direta, pela substituição de caracteres por formas que já povoam o “catálogo cognitivo” do indivíduo, seja por experiência ou proximidade. As formas em interfaces de telas podem compor estruturas imagéticas variadas, porque a interatividade permite que as percepções de percurso, dimensão/conteúdo, parte/todo, ligação, centro/entorno, em cima/embaixo, frente/trás, entre outros sejam representadas por movimentos e ações executadas pelo sistema e pelo usuário, em ciclos de demanda/resposta. Para haver interatividade em telas ou displays de , as imagens precisam buscar e direcionar a interação. Os hiperlinks podem ter relações subjetivas com ações através de imagens e representarem comandos de caminhos a percorrer, através de regras de conhecimento que busquem sentido, assim como assimilam as regras da Gestalt: “o cérebro é um sistema dinâmico no qual se produz uma interação entre os elementos, em determinado momento, através de princípios de organização perceptual como: proximidade,

continuidade,

semelhança,

segregação,

preenchimento, unidade, simplicidade e figura/fundo. Sendo assim o cérebro tem princípios operacionais próprios,

com

tendências

auto-organizacionais

dos

estímulos recebidos pelos sentidos2” As imagens também podem ser referências imagéticas, mas não necessariamente e a todo momento significam o conteúdo. São a base do diálogo e da pertinência de todo o discurso e percurso que o indivíduo percorre em uma interface. Suas ações, dentro de uma determinada tela, estão intrinsecamente direcionadas e ligadas ao objeto do design: a interação humanocomputador. Assim, conforme Platão 3: “(…)se algo parece assim, então esse algo realmente parece assim: a aparência em si mesma deve ser parte da realidade(…)”

2 WIKIPEDIA. Psicologia da forma ou da Gestalt. Acessado em: 11de jan 2011. 3 O SOFISTA. Platão. Acessado em: 11de jan 2011.

Assim, é razoável contribuir para que o processo de desenvolvimento e construção das interfaces concernentes ao projeto Pensando o Direito sejam pensadas de modo a seguir um conceito que seja abrangente e perceptível desde o planejamento, passando pela metodologia e se estendendo até a implementação da aplicação. A consistência em design4 deve ser levada em conta para que as ações do usuário possam ser respondidas e antecipadas no sistema. Para cada input deve haver um output da interface. Essa resposta pode ou não ser visual, mas é importante que se dê de maneira discreta e rápida. Esse feedback é a chave para que o usuário possa ser guiado e se sinta confortável em sua experiência com o dispositivo. A utilização dos conceitos a serem descritos no presente relatório é de suma importância para o bom funcionamento da aplicação, mas sobretudo para que a mesma atinja seus objetivos, que podem ser resumidos em algumas palavras: Diálogo, democracia e compartilhamento de conhecimento. 3. Princípios do desenvolvimento em design5 Existem cânones do design que devem ser obedecidos no momento do desenvolvimento. Segundo Lockwood e Constantine6, eles podem ser resumidos em: •

O princípio da estrutura: o design deve organizar a interface de acordo com o significado das tarefas, baseado em simplicidade, modelos consistentes, alocando itens relacionados e diferenciando itens não similares. O princípio da estrutura está instrinsecamente ligado à arquitetura de informação.



O princípio da simplicidade: o design deve simplificar as tarefas, comunicando com clareza e na linguagem do usuário. Simplicidade também significa prover bons atalhos e procedimentos com significados claros e concernentes ao ambiente do usuário.

4 GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE. Disponível em: Visitado em: 12 de jan 2011. 5 User Interface Design Tips, Techniques, and Principles. Disponível em: Acessado em: 15 de jan de 2011. 6 CONSTANTINE, Larry L. e LOCKWOOD,Lucy A. D.Software for Use: A Practical Guide to the. Models and Methods of Usage-Centered Design. Disponível em: Acessado em: 10 de jan de 2011.



Princípio da visibilidade: tornar uma tarefa visível significa manter todas as opções necessárias para o cumprimento de uma tarefa à disposição e com caminhos curtos para sua realização.



Princípio do feedback: os usuários precisam receber respostas rápidas e serem informados sobre o sucesso ou não das suas ações. É importante que o usuário saiba quando obteve sucesso ou quando sua ação retornou em erro.



Princípio da tolerância: O design deve ser flexível e tolerante, reduzindo a quantidade e a possibilidade de erros.



Princípio da reutilização: o design deve permitir o reaproveitamento de componentes e comportamentos para ações e telas, possibilitando a consistência do sistema e permitindo que os usuários memorizem os itens e caminhos que mais percorrem ou precisam realizar.

3.1.

Multidisciplinaridade

A utilização dos conceitos a serem descritos no presente relatório é de suma importância para o bom funcionamento da aplicação, mas sobretudo para que a mesma atinja seus objetivos, que podem ser resumidos em algumas palavras: 4. Metodologias para produção ágil em design7 4.1.

Domain Driven Design

DDD, como é chamada a técnica, é mais uma filosofia de trabalho do que uma metodologia. Domain Driven Design foi elaborado a partir da observação empírica do designer Eric Evans8 em ambientes de trabalho muito particulares, mas que costumam ser comuns na maioria dos espaços de produção de interfaces. Tais ambientes abrigam excesso de burocracia, falta de recursos, objetivos obscuros, falta de informação sobre o objeto da interface, mudança de contexto constante, entre outros. Para o desenvolvimento de software tais características podem ser extremamente danosas, mas a necessidade da realização do design pode transformar estas características em oportunidades. 7 User Interface Design Tips, Techniques, and Principles. Disponível em: http://www.agilemodeling.com/essays/agileUsability.htm#Misconceptions> Acessado em: 15 de jan de 2011. 8 EVANS, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. 2004, Addison-Wesley.

A palavra “Domain”, traduzida como “domínio” poderia ser traduzida também commo “ambiente de negócio ou serviço”. As oportunidades supracitadas se dão quando o designer procura preencher as lacunas, desmistificando a complexidade do negócio. Assim, o trabalho do designer pode ajudar a esclarecer e estabelecer parâmetros para o negócio, uma vez que o estudo do modelo do mesmo é importante para a consistência do sistema como um todo. Trabalhar sob a filosofia do Domain Driven Design 9 significa conhecer a fundo a natureza do negócio ou objeto da interface, elaborando perguntas sobre os objetivos da interface, a natureza do conteúdo (foto, áudio, vídeo, texto, como o texto é composto etc). É importante não se apegar às tecnologias de framework e sim pensar na natureza do negócio ou serviço. Isso permite maior consistência e oportunidades de prevenção de erros e surpresas nos ciclos de desenvolvimento, ma medida em que não se oprime as possibilidades de interações com base nas limitações tecnológicas. No caso do projeto Pensando o Direito, é importante conhecer a natureza da lei em si, em termos estruturais. Para tal é aconselhado que seja lida a Lei complementar 10 nº 95, de 26 de fevereiro de 1998, que “Dispõe sobre a elaboração, a redação, a alteração e a consolidação das leis, conforme determina o parágrafo único do art. 59 da Constituição Federal, e estabelece normas para a consolidação dos atos normativos que menciona.”. Assim, como as leis são objeto de pesquisa e elaboração de textos acadêmicos, deve estar inserida no contexto do design para que haja pertinência e sentido a partir do design a ser elaborado para os usuários. 4.2.

Combinação de metodologias

Segundo Paula Libardi e Vladimir Barbosa 11, “Uma característica das metodologias ágeis é que elas são adaptativas ao invés de serem preditivas. Dessa forma, elas se adaptam a novos fatores durante o desenvolvimento do projeto, ao invés de tentar analisar previamente tudo o que pode ou não acontecer no decorrer do desenvolvimento. 9 Domain Driven Design COMMUNITY. Apresenta conteúdo sobre melhores práticas no assunto. Disponível em: Acessado em: 10 de jan de 2011. 10 Presidência da República. Disponível em: Acessado em: 20 de jan de 2011. 11 Métodos Ágeis. Monografia para a finalização da matéria "Tópicos em Computação" no curso de pós graduação em Ciência da Computação de Limeira, SP. 2010.

Essa análise prévia é sempre difícil e apresenta alto custo, além de se tornar um problema quando for necessário fazer alterações nos planejamentos. O problema não é a mudança em si, mesmo porque ela ocorrerá de qualquer forma. O problema é como receber, avaliar e responder às mudanças. Numa metodologia clássica pode acontecer de que um software seja construído por inteiro e depois se descubra que ele não serve mais para o propósito que foi desenvolvido porque as regras mudaram e as adaptações tornem-se complexas demais para que valha a pena desenvolve-las. As metodologias ágeis trabalham com constante feedback, o que permite adaptar rapidamente a eventuais mudanças nos requisitos. Alterações essas que são, muitas vezes, críticas nas metodologias tradicionais, que não apresentam meios de se adaptar rapidamente às mudanças. Um outro ponto positivo das metodologias ágeis são as entregas constantes de partes operacionais do software. Desta forma, o cliente não precisa esperar muito para ver o software funcionando e notar que não era bem isso que ele esperava. O ideal para o desenvolvimento ágil em design é que sejam combinadas várias metodologias. Além dos princípios do manifesto ágil 12, citados no produto 02 desta consultora, é aconselhável que sejam seguidas os métodos descritos abaixo: Advindo do desenvolvimento de Software, é interessante adotar o modelo centrado no usuário: “ISO 13407 Human-centered design processes for interactive systems 13”. Este modelo prevê o desenvolvimento de software centrado nas demandas dos usuários primários e secundários (administradores de backend) durante o uso e a fase de coleta de requisitos para desenvolvimento. 12 Acessado em: 02 de dez de 2010. 13 ISO 13407. Norma técnica para desenvolvimento de softwares. Disponível em: Acessado em: 11 de jan de 2011.

Ilustração 1: Esquema de desenvolvimento utilizando a metodologia ISO 13407

A metodologia sugerida na ISO 13407 gera uma curva que se repete com o uso do software, baseado na quantidade de demandas do usuário. A natureza orgânica do software demanda que haja uma preocupação com esse ciclo de desenvolvimento. Para tal, é aconselhável complementar a metodologia citada com uma metodologia do design baseada em archetypes, “Process with feedback14”. Este modelo é baseado nos ciclos de resposta às demandas, sempre tendo como base as demandas dos usuários.

14 PROCESS WITH FEEDBACK. Artigo de caráter acadêmico. Disponível em: Acessado em: 21 de jan de 2011.

Ilustração 2: Esquema para desenvolvimento em design com a metodologia Process with feedback

5. Métodos para pesquisa em Design 5.1.

Card Sorting

É uma ferramenta para pesquisa de rótulos em arquitetura de informação. Com ela é possível que os próprios usuários sugiram os labels que serão utiliados nos botões e outros elementos de ações de uma interface, de modo a tornar o conteúdo mais adaptável e memorizável favorecendo a experiência. De acordo com Frederick Van Amstel, fundador do instituto Faber Ludens,

Card

Sorting15 pode ser aplicado da seguinte forma: “Enquanto aplica o teste, o arquiteto da informação tem a oportunidade de conversar com o usuário sobre a classificação e tomar nota. As escolhas de todos os usuários participantes do teste são cruzadas e os rótulos adquirem uma porcentagem de concordância. Quanto maior, mais indicados para serem usados. O card-sorting pode ser usado para avaliar uma taxonomia existente ou criar uma nova, variando a quantidade de cartões e a liberdade que o usuário tem para adicionar novos rótulos. 15 http://usabilidoido.com.br/cardsorting_classificando_conteudo.html>

Ao final dos testes, o arquiteto da informação quantifica os dados e elabora um relatório resumindo e cruzando as anotações, bem como apresenta a taxonomia sugerida pela média das escolhas dos usuários.” 5.2.

Uso de personagens-símbolo

Dá se o nome de persona ao perfil semiótico dos usuários de um sistema. Assim, o uso de personagens-símbolo para o melhor entendimento do públicos-alvo permite ao designer conhecer as preferências semióticas e portanto imagéticas relacionadas ao universo do target. Assim a consistência do sistema pode ser direcionada a experiências prévias dos usuários. 5.3.

Heurística

É a parte da pesquisa que permite a análise e busca de novos conceitos teóricos ou hipóteses baseadas em conhecimentos empíricos. O procedimento heurístico é o processo de se aproximar dos problemas, assumindo que a heurística é a solução mais próxima do ideal. As heurísticas são argumentos a serem utlizados como reais até que outra hipótese que possa substituir a primeira seja lançada. O conjunto de heurísticas indica caminhos e possibilidades a serem seguidos, e são levantados por pesquisas e análises prévias que indicam a causa da sua formulação, geralmente empírica. Como o design tem como base conceitos de várias áreas, ou seja, é multidisciplinar, é justo partir da constatação de que o desenvolvimento das ciências ocorre de modo desigual para afirmar que a adoção de heurísticas pode encurtar o caminho do pesquisador pois fornece uma série de conhecimentos adquiridos previamente por vários pesquisadores. Assim, Jacob Nielsen, pesquisador e consultor na área de design e usabilidade, estabeleceu dez heurísticas que servem para design de interfaces 16 (tradução livre). A saber: 1. Feedback: •

O sistema deve informar continuamente ao usuário sobre o que ele está fazendo.



10 segundos é o limite para manter a atenção do usuário focalizada no diálogo.

2. Falar a linguagem do usuário •

A terminologia deve ser baseada na linguagem do usuário e não orientada ao sistema.

16 Disponível em: Acessado em: 12 de jan de 2011.



As informações devem ser organizadas conforme o modelo mental do usuário.

3. Saídas claramente demarcadas •

O usuário controla o sistema, ele pode, a qualquer momento, abortar uma tarefa, ou desfazer uma operação e retornar ao estado anterior.

4. Consistência •

Um mesmo comando ou ação deve ter sempre o mesmo efeito. Assim como a mesma operação deve ser apresentada na mesma localização e deve ser formatada/apresentada da mesma maneira para facilitar o reconhecimento.

5. Prevenir erros •

Conhecer as situações que mais provocam erros e modificar a interface para que estes erros não ocorram.

6. Minimizar a sobrecarga de memória do usuário •

O sistema deve mostrar os elementos de diálogo e permitir que o usuário faça suas escolhas, sem a necessidade de lembrar um comando específico.

7. Atalhos •

Abreviações, teclas de função, duplo clique no mouse, função de volta em sistemas hipertexto.



Atalhos também servem para recuperar informações que estão numa profundidade na árvore navegacional a partir da interface principal.

8. Diálogos simples e naturais •

Deve-se apresentar exatamente a informação que o usuário precisa no momento, nem mais nem menos.



A seqüência da interação e o acesso aos objetos e operações devem ser compatíveis com o modo pelo qual o usuário realiza suas tarefas.

9. Boas mensagens de erro •

Linguagem clara e sem códigos.



Devem ajudar a entender e resolver o problema. sem culpar ou intimidar o usuário.

10. Ajuda e documentação •

O ideal é que um software seja tão fácil de usar (intuitivo) que não necessite de ajuda ou documentação. Mas, se for necessária a ajuda deve estar facilmente acessível e on-line.

6. Guidelines para interface 6.1.

Normas técnicas

Para a definição das guidelines para a interface do projeto Pensando o Direito é necessário seguir normas de padronização. É aconselhado que a norma ISO 9241 17 seja somada à cartilha de usabilidade e acessibilidade do e-ping18. Assim, devem ser consideradas as seguintes regras: •

Facilidade de aprendizado;



Facilidade de memorização;



Baixa taxa de erros

6.2.

Elementos principais a) Ícones

São elementos estruturais que devem obedecer à identidade visual do sistema e estarem sob licenciamento adequado para sua reprodução na rede. O uso de ícones é aconselhado 19 apenas se sua substituição por um rótulo for possível. Assim, o ícone deve representar exatamente o significado da ação, para que o usuário não seja confundido ou tenha que adivinhar o que o ícone quer dizer. Para o projeto Pensando o Direito sugere-se a utilização de um set de ícones já existente e licenciado de forma adequada, de modo a economizar recursos e aproveitar insumos distribuídos na internet por projetos livres. A vantagem disso é que o estabelecimento dos significados, parte complexa da construção de ícones de uma interface, já vem resolvida, posto que as ações comuns que podem ser realizadas em uma interface já foram mapeadas exaustivamente.

17 ISO (1999). ISO 13407: Human-centred design processes for interactive systems. Gènève: International Organisation for Standardisation. Disponível em: Acessado em 03 de jan de 2011. 18 NORMAS PARA USABILIDADE. Padrões e-ping. Disponível em: Acessado em: 10 de jan de 2011. 19 Introduction to Good Usability. CONRADIE, Peter. (2008).

Ilustração 3: Exemplo do set de ícones Humanoid Nearly Human aplicado ao Ubuntu

Assim, o set de ícones utilizado pelo Ubuntu 9.0, baseado nas guidelines do Projeto Gnome20, chamado “Humanoid-nearly-Human” - desenvolvido por Schoollidesign 21 e licenciado em GPL-222 é a sugestão desta consultora para que o projeto possa adquirir consistência em sua comunicação das ações comuns. Apesar de ser um set de ícones feitos para povoar sistemas operacionais, ações básicas como “busca” e a indicação de arquivos, por exemplo, podem ser reaproveitadas com sucesso. b) Principais ações indicadas23: •

Set de ações para blogs: comentar, enviar comentário, ou responder; classificar conteúdo; compartilhar; enviar; curtir (facebook);

20 PROJETO GNOME. Guidelines for icons. Disponível em: Acessado em: 12 de jan de 2011. 21 DEVIANTART. Disponível em: Acessado em: 12 de jan de 2011. 22 GNU.ORG. Licences. Disponível em: Acessado em: 12 de jan de 2011. 23 UI PATTERNS. Disponível em: Acessado em: 04 de jan de 2011



Sistema: reportar erro; assinar feed; avançar, voltar; fechar; abrir; fazer download; registrar-se; logon/logoff; ir para; buscar; busca avançada; voltar para a home;



Visualização de redes sociais: últimos tweets, identi.ca; badge do facebook; acompanhe na rede (orkut, facebook, twitter, identi.ca, netvibes, blogblogs); links pertinentes; movimentação por hashtags;

Sem mais nada a acrescentar à diposição para esclarecimentos. Brasília, 07 de fevereiro de 2011

Yasodara Maria Damo Córdova Consultora PNUD

Lihat lebih banyak...

Comentários

Copyright © 2017 DADOSPDF Inc.