<?xml version="1.0" encoding="utf-8"?>
<chapter id="principles" lang="pt-BR">
    
    <title>Princípios de usabilidade</title>

    <para>Esta seção explica alguns princípios básicos por trás das diretrizes técnicas mais específicas recomendadas nesse documento. Nós acreditamos que esses princípios são importantes para todo o desenvolvimento do aplicativo.</para>

    <sect1 id="principles-people">
      <title>Projete para as pessoas</title>

      <para>Lembre-se que o propósito de qualquer aplicativo de software é permitir que um grupo de pessoas realize um conjunto específico de tarefas. Então, as primeiras coisas a estabelecer quando projetar seu aplicativo são:</para>

	<orderedlist>
		<listitem><para>quem são seus usuários</para></listitem>
		<listitem><para>o que deseja possibilitá-los a fazer</para></listitem>
	</orderedlist>

      <para>Por exemplo, você pode estar projetando um aplicativo que irá possibilitar engenheiros (de software, elétricos ou mecânicos) a criar diagramas. Você pode estar projetando um aplicativo que irá possibilitar administradores de sistema a configurar e monitorar um servidor web. Você pode estar projetando um aplicativo que irá ajudar alunos do ensino fundamental a estudar matemática.</para>

      <para>O importante é que você conheça seu público, e entenda tanto suas metas quanto as tarefas necessárias para alcançar essas metas. Existe um grande número de designers de interação profissionais que escrevem livros e ministram cursos sobre métodos de design que podem ajudar neste processo, muitos dos quais são extremamente úteis - veja a <xref linked="bibliography"/> para uma seleção. A maioria desses métodos, entretanto, reduzem-se a maneiras específicas de entender seus usuários, entender as tarefas que deseja ajudá-los a realizar, e encontrar maneiras de admitir essas tarefas no seu aplicativo.</para>

    </sect1>
    <sect1 id="principles-broad-userbase">
      <title>Não limite sua base de usuários</title>

      <para>Se você está projetando um aplicativo para ser utilizado por engenheiros, ou por crianças, ou por administradores de sistemas, certifique-se de um aplicativo que possa ser utilizado por <emphasis>todos</emphasis> os engenheiros, crianças ou administradores de sistemas, incluindo aqueles com deficiências ou aqueles que são falantes nativos de uma língua diferente da sua. Esteja ciente das questões de acessibilidade, internacionalização e localização, muitos dos quais são endereçados pelas diretrizes neste documento.</para>

      <sect2 id="accessibility">
	<title>Acessibilidade</title>

	<para>Acessibilidade (às vezes chamado <emphasis>a11y</emphasis>) significa possibilitar pessoas com deficiências de algum tipo a participar de atividades da vida: neste caso, especificamente, usar seu software. Por exemplo:</para>

	<itemizedlist>
		<listitem><para>Usuários daltônicos podem não ser capazes de utilizar seu aplicativo se você depender apenas de cores para distinguir diferentes tipos de informação</para></listitem>
		<listitem><para>Usuários com deficiências auditivas podem não ser capazes de utilizar seu aplicativo se você depender de sons para indicar informações críticas</para></listitem>
		<listitem><para>Usuários com movimentos limitados podem não ser capazes de utilizar seu aplicativo se você não fornecer equivalentes do teclado para comandos</para></listitem>
	</itemizedlist>

	<para>Seu aplicativo também deve ser utilizável com interfaces de voz, leitores de tela como <ulink url="http://projects.gnome.org/orca/">Orca</ulink>, dispositivos de entrada alternativos, e outras tecnologias assistivas. As bibliotecas padrão do GNOME fazem a maior parte do trabalho para você, mas com um pequeno esforço adicional você pode fazer seu aplicativo tão útil para os usuários que dependem destas tecnologias como para aqueles que não dependem.</para>

	<para>O GNOME possui um excelente suporte embutido para acessibilidade por meio das bibliotecas ATK e GAIL, as quais em vários casos podem fazer a maior parte do trabalho para você. Mais informações sobre acessibilidade no GNOME podem ser encontradas em <ulink url="http://projects.gnome.org/accessibility">Projeto de acessibilidade GNOME</ulink>.</para>

      </sect2>
      <sect2 id="internationalization">
	<title>Internacionalização e localização</title>

	<para>Internacionalização significa projetar software de modo que possa funcionar em ambientes de linguagem diferentes. Localização é o processo de traduzir as mensagens, etiquetas e outros elementos de interface de um aplicativo em outra língua.</para>

	<para>O GNOME possui um suporte excelente tanto para internacionalização (também referido como i18n) e localização (também referido como l10n). Na maioria das vezes, simplesmente usar as APIs padrão do GNOME para exibir texto e mensagens permitirá que você ou outros localizem seu aplicativo para outras localidades. Para mais informações sobre como fazer seu aplicativo localizável, veja a <ulink url="http://www.pango.org">página inicial do projeto Pango</ulink> (Pango é a biblioteca do GNOME para renderizar texto internacionalizado), a <ulink url="http://www.gnome.org/i18n/">página de traduções do GNOME</ulink> e a <ulink url="http://developer.gnome.org/projects/gtp/">página do projeto de tradução de GNOME</ulink>.</para>
	
	<para>Sensibilidade para questões culturais e políticas também uma consideração importante. Projetar ícones e sons, e até mesmo escolher cores requer algum entendimento das conotações que podem tem para um usuário de uma parte diferente do mundo.</para>
	<para>Exemplos de elementos que é melhor evitar por essas razões incluem:</para>
	<itemizedlist>
		<listitem><para>Figuras de bandeiras ou dinheiro</para></listitem>
		<listitem><para>Mapas mostrando limites políticos ou nomes controversos de locais</para></listitem>
		<listitem><para>Listas de países ou cidades em ordem não-alfabética (a menos que seja especificamente solicitado ou requerido pelo contexto)</para></listitem> 
		<listitem><para>Ícones representando animais</para></listitem>
		<listitem><para>Ícones representando apenas mãos ou pés</para></listitem>
	</itemizedlist>

      </sect2>
    
    </sect1>

    <sect1 id="principles-match">
      <title>Crie uma correspondência entre seu aplicativo e o mundo real</title>

      <para id="use-users-language">Sempre use palavras, frases e conceitos que são familiares para o usuário antes de termos do sistema subjacente. Use termos que estão relacionados ao conhecimento do usuário das tarefas que seu aplicativo suporta. Por exemplo, na medicina, a pasta de papéis que contém todas as informações sobre um paciente específico é chamado de "prontuário". Por isso, um aplicativo médico pode se referir ao registro do paciente que contém a mesma informação de um prontuário como "prontuário do paciente" ao invés de "registro de dados do paciente".</para>

      <para>Você frequentemente pode tirar proveito do conhecimento do mundo real de seu usuário usando metáforas — isto é, um conceito familiar do mundo externo — para representar elementos internos ao seu aplicativo. Por exemplo:</para>

	<itemizedlist>
		<listitem><para>uma imagem de uma pasta de arquivos sugere um contêiner no qual documentos podem ser colocados</para></listitem>
		<listitem><para>um cesto de lixo sugere um contêiner no qual itens podem ser colocados quando não são mais necessários</para></listitem>
	</itemizedlist>

      <para>Quando usar metáforas, entretanto, é importante nem levar a metáfora de modo muito literal, nem estender a metáfora além de seu uso sensato. Por exemplo, a capacidade de uma pasta de arquivos não deve ser limitada à capacidade de uma pasta de arquivos física, que presumidamente pode conter apenas alguns documentos antes de se tornar pesado. Por outro lado, uma cesta de lixo não deve ser usada para nada além de reter arquivos descartados. Não deve ser utilizada, por exemplo, para ejetar um disco removível como um disquete ou um CD.</para>
    </sect1>

    <sect1 id="principles-consistency">
      <title>Faça seu aplicativo consistente</title>

      <para>Faça seu aplicativo consistente consigo mesmo e com outros aplicativos, tanto na sua aparência quanto em seu comportamento. Este é um dos princípios de design mais importantes, e provavelmente o mais famoso, mas também frequentemente ignorado. Embora este documento sirva como base para consistência entre aplicativos do GNOME, você é encorajado a ver e seguir outras convenções de aplicativos onde esse documento não oferece nenhuma diretriz.</para>

      <para>Consistência permite aos usuários aplicar seu conhecimento existente sobre o ambiente de computação e outros aplicativos para entender um novo aplicativo. Isso não apenas permite que os usuários se familiarizem com novos aplicativos mais rapidamente, mas também ajuda a criar uma sensação de conforto e segurança no ambiente como um todo. A maioria das recomendações nas diretrizes de interface humana do GNOME são projetadas para ajudá-lo a criar aplicativos que são consistentes com o ambiente GNOME e outros aplicativos GNOME.</para>

      <para>Uma palavra de cautela: uma consistência mal aplicada ou incompleta é frequentemente pior que uma inconsistência. Caso seu aplicativo inclua um item de menu <guimenuitem>Desfazer</guimenuitem> para consistência, mas esteja sempre desabilitado porque seu aplicativo atualmente não suporta Desfazer, isto reduzirá a confiança do usuário na disponibilidade do Desfazer em outros aplicativos no ambiente de trabalho. Ou faça seu aplicativo suportar o Desfazer, ou elimine o item <guimenuitem>Desfazer</guimenuitem> do menu.</para>

    </sect1>

    <sect1 id="principles-feedback">
      <title>Mantenha o usuário informado</title>

      <para>Sempre permita que o usuário saiba o que está ocorrendo em seu aplicativo usando o comentário (feedback) apropriado no momento apropriado. O usuário nunca deve supor sobre o estado do sistema ou do seu aplicativo. Quando o usuário realizar uma ação, providencie comentários (feedback) para indicar que o sistema recebeu a entrada e está operando nela. O comentário (feedback) pode ser visual, sonoro, ou ambos. Caso o sistema vá levar um longo tempo para processar a requisição, providencie tanto comentário (feedback) quanto possível sobre como a operação será prolongada. Tipos de comentário (feedback) úteis incluem, mas não são limitados a: mudanças no cursor, pulsadores animados, indicadores de progresso, retorno sonoro como um bip, e mensagens de erro. Mensagens de erro devem usar uma linguagem simples, expor claramente o problema, e fornecer soluções ou dizer ao usuário como sair da situação atual se possível.</para>

      <para>É crítico que o comentário (feedback) seja <emphasis>correto</emphasis> e <emphasis>preciso</emphasis>. Caso você exiba um determinado indicador de progresso para mostrar o estado de completude de uma tarefa e estiver incorreto, o usuário perderá a confiança em indicadores de progresso, e achará o ambiente menos utilizável. Se você exibir uma mensagem de erro genérica que indica que há um problema, mas falha em fornecer informação suficiente para diagnosticar ou resolver o problema, seus usuários serão incapazes de continuar com sua tarefa.</para>
      <para>Veja <xref linkend="feedback"/> e <xref linkend="windows-alert"/> para mais informações sobre retorno.</para>
    </sect1>

    <sect1 id="principles-simplicity">
      <title>Mantenha simples e belo</title>

      <para>Seu aplicativo deve permitir que o usuário se concentre na tarefa em mãos. Então, projete seu aplicativo para mostrar apenas informações e elementos da interface úteis e relevantes. Cada pedaço de informação ou controle de interface extra compete com as partes verdadeiramente relevantes de informação e distraem o usuário da informação importante. Por isso, não polua visualmente sua interface, e não sobrecarregue o usuário com botões, opções de menu, ícones ou informação irrelevante. Ao invés disso, use relevação progressiva e outras técnicas para limitar o que o usuário vê em um dado momento.</para>

      <para>Finalmente, apresente sua informação e os elementos da interface de uma maneira esteticamente agradável. Uma interface desorganizada e visualmente poluída com poucos elementos pode distrair tanto quanto uma interface organizada com muitas informações. Certifique-se de que elementos de diálogo são claramente alinhados, e não faça uso excessivo ou errôneo de cores e gráficos. Caso você conheça um designer gráfico, procure por aconselhamento se possível — as diretrizes neste documento ajudarão com o básico, mas não há substituto para um olho treinado.</para>

	<para>Veja <xref linkend="design"/> e <xref linkend="icons"/> para mais informações sobre projetar a aparência visual de seu aplicativo.</para>

    </sect1>

    <sect1 id="principles-user-control">
      <title>Coloque o usuário no controle</title>

      <para>Lembre-se que computadores existem para servir humanos. Um usuário deve sempre se sentir no controle, capaz de fazer o que quiser quando quiser. Isso significa que você geralmente deve evitar modos; usuários devem ser capazes de mudar entre diferentes tarefas (e especificamente, diferentes janelas) a qualquer hora. Veja <xref linkend="window-props-modality"/> para mais informações sobre modos.</para>

      <para>O usuário deve também ser capaz de adaptar os aspectos do seu ambiente para se adequarem às suas preferências pessoas. É muito importante, entretanto, evitar a armadilha de permitir muita configuração, ou permitir a configuração de parâmetros que a maioria dos usuários não entenderá ou achará útil modificar. Onde for possível, herde parâmetros visuais e comportamentais das preferências e configurações globais como o tema atual do GTK+.</para>
    </sect1>

    <sect1 id="principles-forgiveness">
      <title>Perdoe o usuário</title>

      <para>Todos nós cometemos erros. Seja explorando e aprendendo como usar o sistema, ou especialistas que pressionaram o botão errado, somos apenas humanos. Seu aplicativo deve portanto permitir os usuários a rapidamente desfazer os resultados de suas ações.</para>

      <para>Se uma ação é muito perigosa e não há um modo de desfazer o resultado, alerte o usuário e peça pela confirmação. Faça isso apenas em casos extremos, entretanto; se deparados frequentemente com tais mensagens de confirmação, usuários começam a ignorá-las, tornando-as pior do que inúteis.</para>

      <para>Em todos os casos, o trabalho do usuário é sacrossanto. Nada que seu aplicativo faça deve perder ou destruir o trabalho do usuário sem uma ação explícita do usuário. Entre outras técnicas, isso pode ser alcançado com o salvamento automático de cópias de segurança, e permitindo múltiplos níveis de desfazer.</para>

    </sect1>

    <sect1 id="principles-direct-manipulation">
      <title>Forneça manipulação direta</title>

      <para>Sempre que possível, permita que os usuários ajam em objetos e informações diretamente, em vez de diálogos ou comandos explícitos. Por exemplo, é mais intuitivo arrastar um objeto circular em um diagrama do que selecionar um comando "mover" do menu enquanto o círculo é selecionado. Similarmente, em um aplicativo de email, permita que o usuário anexe arquivos arrastando-os do gerenciador de arquivos e soltando-os na janela de composição de mensagens caso queiram.</para>

	<para>Veja <xref linkend="input"/> para mais informações sobre manipulação direta.</para>

    </sect1>

  </chapter>
