Diretrizes de Interface Humana

These guidelines are designed to help developers and designers create a beautifully consistent experience on the elementary OS desktop. They were written for interface designers, graphic artists and software developers who will be working on elementary OS. They will not only define specific design elements and principles, but will also instill a philosophy that will help you decide when it is appropriate to deviate from the Guidelines. Adhering to the suggestions contained here will provide many benefits:

Para ajudar a alcançar estes objetivos, estas diretrizes cobrirão os elementos básicos de interface, como usá-los e integrá-los com eficiência, e como fazer sua aplicação integrar-se melhor com o sistema. O mais importante a se lembrar é que seguir estas diretrizes tornará mais fácil a criação de uma nova aplicação, e não mais difícil.

Entretanto, tenha em mente que estas são orientações, não um livro de regras. Novos, incríveis paradigmas de interação surgem todos os dias e muitos ainda esperam ser descobertos. Este é um documento vivo que pode e será modificado.

Para seções que ainda não foram escritas, por favor dirija-se a The GNOME HIG - How's It Going - A máxima de como isso funciona

Filosofia do Design

The elementary OS HIG isn't just about a set of concrete rules; it's meant to be flexible and extensible. As such, this very first portion of the guideline is all about the guiding philosophy we employ. For a quick crash course, we like "The User is Drunk":

O Que Design Não É

Before we get into all the things that make up elementary OS apps, there is a clarification that needs to be made. We need to understand what exactly design is about, but more importantly we want to smash two major myths:

  1. Design não é algo que você acrescenta depois de finalizar um produto. Percebendo ou não, você está constantemente usando Design em tudo que constrói. É uma parte intrínseca da criação de algo. Design não é apenas como a aparência de uma coisa. Ele não é sobre cores e fontes. Design é como ela funciona. Quando você decide adicionar um botão que faz algo, isto é design. Você toma a decisão de adicionar um botão com um ícone ou uma legenda e para onde aquele botão vai e o tamanho e cor do botão. Decisões são designs.

  2. Design não é gosto pessoal. Design é testável. Um design vai alcançar um objetivo específico melhor que outro design. Considere diferentes tipos de bicicleta. Uma bicicleta dobrável tem um conjunto de objetivos diferente de uma bicicleta de montanha. Coisas como peso, tamanho, e tipo de pneu são fatores importantes para ajudar um possível usuário a alcançar seu objetivo. Por compreendermos que design é sobre resolver problemas específicos, nós também devemos compreender que podemos comparar objetivamente a eficácia de dois designs em resolver esses problemas.

  1. Design Não É Aparência, Aral Balkan
  2. Design Não É Subjetivo, Jeff Law

Concisão

Sempre trabalhe para tornar seu app fácil de entender. A principal função do seu app deve se destacar de imediato. Você pode fazer isto de várias maneiras, mas uma das melhores delas é se manter a um princípio de concisão, visando apenas aquilo que é essencial.

Evite o Inchaço de Funcionalidades

É sempre muito tentador continuar adicionando mais e mais funcionalidades para a sua aplicação. Contudo, é mais importante reconhecer que toda nova funcionalidade tem um preço. Especificamente, cada vez que você adiciona uma nova funcionalidade:

Pense em Módulos

Build small, modular apps that communicate well. elementary OS apps avoid feature overlap and make their functions available to other apps either through Contractor or over D-Bus. This both saves you time as a developer (by other apps making their functions available to you), and is a courteous gesture towards other developers (by making your app's functions available to them).

Evite Configurações

Se possível, evite completamente apresentar qualquer definição ou configuração no seu app. Fornecer configurações é, geralmente, um jeito fácil de tomar as decisões de design sobre o comportamento do seu aplicativo. Mas, como os problemas de inchaço de funcionalidades, configurações significam mais código, mais bugs, mais testes, mais documentação e mais complexidade.

Construa para uma Experiência "Fora da Casinha".

Design with sane defaults in mind. elementary OS apps put strong emphasis on the out of the box experience. If your app has to be configured before a user is comfortable using it, they may not take the time to configure it at all and simply use another app instead.

Pergunte ao Sistema Operacional

Consiga o máximo de informação automatizada possível. Ao invés de perguntar a um usuário pelo seu nome ou sua localização, pergunte ao sistema por estas informações. Isto diminui a quantidade de coisas que um usuário deve fazer e faz o seu app parecer inteligente e integrado.

Você Realmente Precisa Disto?

Pergunte a você mesmo se a opção de configuração que está adicionando é realmente necessária ou faz sentido para o usuário. Nunca peça a um usuário para tomar decisões de engenharia e de design.

Quando Você Realmente Precisa

Mantenha as coisas no contexto. Ao invés de jogar preferências em uma janela de configuração, pense em exibi-las no contexto dos objetos que elas afetam (parecido como as opções de embaralhamento e de repetição aparecem na sua biblioteca de música).

Se o seu app precisa ser configurado antes de ser utilizado (como um cliente de e-mail), exiba esta configuração dentro da janela principal, como uma Tela de Boas Vindas. Mais uma vez, tenha certeza de que é uma configuração necessária. Adicionar telas de configuração desnecessárias impedem os usuários de fazer o que eles queriam fazer quando abriram o seu app.


Veja Também:

  1. Checkboxes That Kill Your Product por Alex Limi
  2. Don't Give Your Users Shit Work por Zach Holman
  3. The Wizard Anti-Pattern por Stef Walter

Documentação Mínima

A maioria dos usuários não quer ler documentos de ajuda antes de poderem usar seu app. Em vez disso, eles esperam que o seu aplicativo seja intuitivo e simples, de modo que eles entendam sem qualquer ajuda.

Use Copia Compreensível

Evite jargões técnicos e assuma de pouco a nenhum conhecimento técnico. Isso faz com que seu app seja 'auto-documentável'.

Disponibilize explicações não-técnicas ao invés de mensagens de erro críticas. Se algo der errado, uma explicação simplificada do que aconteceu e como resolver deve ser apresentada.


Para mais informações, veja Estilo de Escrita.

Fluxo de trabalho do usuário

Design visível é uma grande parte da experiência do usuário, mas também é o fluxo de trabalho do usuário, ou como ele interage com um aplicativo. Nesta seção, nós cobrimos alguns passos importantes de um típico fluxo de trabalho:

Experiência de Primeiro Uso

Configuração Requerida

When a user first launches an app, they should be able to get down to business as quickly as possible. If configuration is not absolutely required for the first use, they should not be required to configure anything. If configuration is required, they should be presented with a clean and simple welcome screen within the app. Avoid separate configuration dialogs when launching.

Velocidade de lançamento

A primeira execução da sua aplicação é a primeira impressão que o usuário terá dela; é uma chance de realmente mostrar seu design e performance. Se sua aplicação precisa de algum processamento antes de mostrar algo visível, isso dá ao usuário a impressão que a aplicação é lenta ou que levará muito tempo para iniciar. Ao invés disso, foque em fazer a janela da aplicação aparecer rapidamente e pronta para ser usada, somente depois faça qualquer processamento paralelo necessário. Se alguma tarefa paralela é bloqueante (ie. o usuário fica inabilitado de utilizar a aplicação até que a tarefa termine), mostre algum tipo de indicador sobre isso e deixe os items da interface que está bloqueada com menor destaque (veja: Conceitos de Widgets)

Dando boas-vindas ao Usuário

Se não houver conteúdo a ser mostrado ao usuário, forneça ações que eles podem realizar através de uma simples tela de boas vindas. Permita-os abrir um documento, adicionar uma conta, importar um CD, ou qualquer coisa que fizer sentido no contexto do aplicativo.

Redefinindo o aplicativo

Se um usuário explicitamente "reconfigurar" o aplicativo (ex. deletando todas as músicas em uma biblioteca de músicas ou removendo todas as contas de e-mail em um cliente de e-mail), o aplicativo deve retornar para o seu estado inicial.

Lançamento normal

Quando um usuário executa um aplicativo, ele está realizando uma ação explícita e esperando uma resposta rápida, muitas vezes imediata. Você deve focar em três áreas chaves para a execução do aplicativo: velocidade, obviedade do que fazer a seguir, e estado.

Velocidade

Como já foi dito antes, a velocidade, especialmente ao lançar um aplicativo, é muito importante. Deve ter o menor atraso possível entre o momento em que um usuário decide lançar um aplicativo e no instante em que pode começar a usá-lo. Se o seu aplicativo exige uma tela de carregamento, você está fazendo errado.

Obviedade

Quando um usuário inicia o aplicativo, eles devem saber exatamente o que fazer a seguir. Isto é conseguido, seguindo as outras diretrizes de interface (assegurando o seu aplicativo é compatível com outros aplicativos) e oferecendo-se ações explícitas. Se o aplicativo tipicamente exibe "itens", como músicas ou e-mails, permitir que o usuário chegar a esses itens, exibindo-os quando o aplicativo é aberto. Se não houver itens previamente abertos, você deve oferecer para abrir ou criar um novo item (como um documento) usando um tela bem-vindo.

Estado

Se o usuário tiver usado anteriormente o seu aplicativo, é tipicamente melhor para restaurar o estado do aplicativo quando abri-lo novamente. Isso significa que o aplicativo vem-se para a direita, onde o usuário parou para que eles possam pegar seu trabalho novamente. Para um leitor de música, isso significa abrir-se com a visão de onde o usuário deixou a música parou e onde o usuário fechou o aplicativo. Para um editor de documentos, isso significaria a abertura com o mesmo documento deslocado para o mesmo local com o cursor no mesmo local na página.

Sempre Permita Desfazer

As vezes um usuário realizará uma ação que pode ser destrutiva ou irreversível. Ao invés de mostrar um aviso ao usuário, apps devem permitir que o usuário desfaça a ação um número apropriado de vezes. Alguns ótimos exemplos de quando esse comportamento é útil são:

Esse comportamento apenas como ultimo recurso deve ser implementado utilizando um buffer de tempo entre quando o app mostra ao usuário o que aconteceu e quando a ação realmente é realizada. Para manter o a experiencia responsivel, o app deve sempre parecer que a ação ocorreu assim que o usuário à inicia.

Esse comportamento alcança o melhor balanço de se manter fora do caminho do usuário enquanto garante que o usuário não faça nada sem querer. É importante manter a ação de desfazer discreta e ao mesmo tempo simples e intuitiva; uma forma comum de fazer isso é utilizando a barra de informações, mas outros métodos também podem ser apropriados.


Veja também: Never Use a Warning When you Mean Undo por Aza Raskin

Sempre Salvo

Usuários devem se sentir confiantes quando usando elementary; eles devem saber que tudo que eles veem está salvo e atualizado.

Apps no elementary devem operar supondo um estado sempre salvo. Isso significa que qualquer mudança que o usuário faça deve ser aplicada instantaneamente e visível e que fazer o usuário salvar configurações é coisa do passado ou comportamento especial.

Por exemplo, o dialogo de informação de uma música deve atualizar a informação da faixa instantaneamente sem que o usuário tenha que pressionar o botão para salvar, preferencias do usuário devem ser aplicadas assim que o usuário interagir com o widget relevante, e fechar um app deve significar que ao reabri-lo ele irá retornar de onde o usuário o deixou.

Fechamento

Quando um usuário fecha um aplicativo, geralmente é porque já termiram de usá-lo por agora e querem tirá-lo do caminho.

Salvando estado

Aplicativos devem salvar seu estado atual quando fechados para que eles possam ser reabertos exatamente de onde o usuário parou. O ideal é que fechar e reabrir um aplicativo deve ser distinto do conceito tradicional de minimizar e desminimizar um aplicativo; ou seja, todos os elementos devem ser guardados, incluindo os documentos abertos, posição de rolagem, desfazer a história, etc.

Tarefas em segundo plano

Se isso faz sentido para um aplicativo para completar tarefas em segundo plano depois que a janela é fechada, as tarefas devem ser concluídas em breve depois que a janela é fechada. Se o aplicativo executa tarefas em segundo plano de repetição (como um cliente de email), as tarefas em segundo plano deve ser tratado por um "daemon" (serviço) separado que não contam com o aplicativo em si ser aberto.

Fechando a janela do aplicativo

Não é desejável para uma janela do aplicativo para minimizar ao invés de simplesmente fechar quando o usuário tenta fechar. Em vez disso, a janela do aplicativo deve ser "escondido". Se isso faz sentido continuar um processo em segundo plano (como o download / transferência, a reprodução de música, ou executar um comando de terminal) o backend aplicativo deve continuar com a tarefa e fechar quando a tarefa estiver concluída. Se não for imediatamente evidente que o processo foi concluído (como acontece com o download do arquivo / transferência ou comando terminal), o aplicativo pode mostrar uma notificação informando ao usuário que o processo foi concluído. Se é evidente, como acontece com a música, nenhuma notificação é necessária.

Reabrindo a janela do aplicativo

Se o usuário re-abre o aplicativo enquanto o processo em segundo plano ainda está em execução, o aplicativo deve iniciar exatamente onde parou. Por exemplo, o terminal deve mostrar qualquer saída terminal, o leitor de música deve ser na mesma página que foi quando fechada, e o navegador deve voltar para a página que foi em anteriormente. Para mais detalhes, veja a discussão do estado de aplicativo em um Lançador Normal.


Veja tambpém: É Isso Aí, Estamos Encerrando por Matthew Paul Thomas

Integração com Desktop

An important advantage that developers have when choosing the elementary OS platform is the ability to seamlessly integrate their application with the default desktop. Outlined below are the several ways in which you can make your application feel beyond native in elementary. This section will cover things like:

Lançadores de aplicativos

O método primário de descobrir e usar seus aplicativos será através do lançador encontrado no Slingshot ou na sua barra de inicialização. Para ter acesso a esses lançadores de aplicativos você precisa instalar um arquivo .desktop apropriado com seu aplicativo. Isto inclui dar ao seu lançador um nome apropriado, colocá-lo na categoria correta, designá-lo um ícone, etc.

Arquivos .desktop seguem a Desktop Entry Specification do freedesktop.org. Eles devem ser instalados em /usr/share/applications. Usuários podem criar seus próprios atalhos colocando os arquivos .desktop em ~/.local/share/applications.

O conteúdo dos arquivos .desktop deve seguir esta fórmula:

Título é um(a) GenericName que lhe permite Comentar.

Título

Você não deve usar palavras descritivas em seus títulos. Por exemplo, Dexter é chamado de "Dexter", e não "Contatos Dexter". Midori é apenas "Midori", e não "Navegador Midori". Em vez disso, utilize o atributo GenericName no arquivo .desktop dos seus aplicativos para nomes comuns, e o atributo Comment para uma frase descritiva mais longa.

NomeGenérico

Se o seu aplicativo é facilmente categorizado ou descrito com um nome genérico, você deve usá-lo para o atributo GenericName no arquivo .desktop do seu aplicativo. Se você pode dizer, "Meu aplicativo é um(a) ____," então o que se encaixa no espaço em branco pode ser o nome genérico. Por exemplo, Maya é um calendário, portanto o seu nome genérico é "Calendário"

Você não deve incluir artigos (o, a, um) ou as palavras "programa", "app", ou "aplicação" no nome genérico do seu aplicativo.

O nome genérico deve ser com iniciais em maiúsculo e pode ser usado em todo o sistema para melhor descrever ou categorizar seu aplicativo.

Comente

O sistema usa o atributo Comment de um aplicativo (encontrado no arquivo .desktop) para informar o usuário sucintamente sobre o que pode ser feito com ele. O atributo deve ser uma sentença ou frase que comece com um verbo e que contenha os substantivos primários com os quais o seu aplicativo lida. Por exemplo, os comentários a seguir são apropriados:

Um comentário de aplicativo deve estar em caixa baixa não incluindo pontuação de finalização (pontos finais, exclamações ou pontos de interrogação), e deve ser tão curto quanto possível enquanto descreve a função primária do aplicativo.

Categorias

As seguintes categorias podem ser usadas para auxiliar com a pesquisa ou navegação para seu aplicativo:

Para mais informações, consulte a especificação de entrada do menu FreeDesktop.Org

Palavras-chave

Você pode também incluir palavras-chave em seu lançador para ajudar usuários a encontrar seu aplicativo via busca. Elas seguem a convenção de "X-GNOME-Palavras-chave" (para o lançador do aplicativo) e "X-Instalador-Palavra-chave" (para o instalador do aplicativo). Por exemplo, navegadores podem incluir "Internet" como uma palavra-chave, mesmo não sendo o nome do aplicativo, seu nome comum ou sua descrição. Como resultado, um usuário que procure por "Internet" encontrará o aplicativo. Aqui estão mais alguns exemplos:

Palavras-chave devem ser palavras únicas (em título casual) separadas por ponto-e-vírgula.


Veja também: Especificação de Entrada da Área de Trabalho de FreeDesktop.org

Contratante

Contractor é um serviço e um protocolo que expõe facilmente serviços entre aplicativos. Ele permite que um aplicativo interaja com outros aplicativos e serviços sem a necessidade de suporte pré-programado para eles. Você simplesmente adiciona suporte de Contractor, e então qualquer serviço registrado em Contractor estará disponível para o seu aplicativo usar. Seu aplicativo pode integrar-se com Contractor de duas maneiras diferentes:

Exibindo Resultados do Contractor

Resultados de Contractor são tipicamente apresentados ao usuário em forma de menu. Lembre-se do seguinte ao apresentar resultados de Contractor:

Integração do Dock

Integre seu aplicativo com o dock do Pantheon para comunicar ao usuário o seu estado em instantes.

Barras de Progresso

Faça barras de progresso inequívocas referindo-as a uma tarefa única e específica. Por exemplo, use barras de progresso para indicar o estado de processos longos como transferências de arquivos e codificação. Não use barras de progresso para combinar o progresso de tipos de ações diferentes.

Emblemas

Um indicador de ações mostra a quantidade de itens a serem lidados que são gerenciados pelo seu aplicativo. Seu propósito é informar ao usuário de que existem itens necessitando atenção ou ação sem incomodar. É uma notificação passiva. Um indicador de ações não deve mostrar totais ou contadores que raramente mudam. Se um indicador de ações não é facilmente removido quando o usuário vê seu aplicativo, é provável que não seja um bom uso de um indicador de ações.

Indicadores do Sistema

Indicadores são pequenos ícones que vivem no painel superior. Eles dão aos usuários um lugar para rápida visualização de várias configurações ou eventos. Clicar no ícone exibe um pequeno menu com ações relacionadas disponíveis para o usuário.

Seu Aplicativo Precisa de um Indicador?

A área dos indicadores é sujeita a bagunça e paradigmas inconsistentes. Assumindo que os usuários vão provavelmente instalar vários aplicativos de terceiros, temos que ser cuidadosos com a quantidade de indicadores que mostramos e com seus comportamentos. Lembre-se que apenas uma pequena quantidade de aplicativos precisam ou se beneficiam de um indicador. Evite adicionar um indicador se:


Veja também: Adeus à Área de Notificação por Matthew Paul Thomas

Container Widgets

Janelas

Janelas formam a fundação do seu aplicativo. Elas fornecem uma tela com ações básicas integradas tais como "fechar" e "redimensionar". Embora os usuários possam pensar que janelas são todas iguais, elementary OS possui vários tipos distintos de janelas. É importante entender os tipos de janelas disponíveis, o seu comportamento geral, e o comportamento específico de um certo tipo de janela. Esta seção cobrirá os tipos diferentes de janelas disponíveis em elementary OS. Embora cada tipo de janela seja um pouco diferente, pense nelas como subclasses de uma janela. Exceto quando avisado, todas elas se comportam como uma janela normal.

Títulos de Janelas

Ao lidar com títulos de janelas, considere que seu principal uso é para distinguir uma janela de outra. Um bom título de janela fornecerá uma descrição que ajude o usuário a fazer uma seleção. Tenha isso em mente ao considerar o seguite:

Diálogos

24
Ícone de alerta em caixas de diálogo

Texto principal fornecendo informações básicas e uma sugestão

Texto secundário fornecendo maiores detalhes. Também inclui informações que explicam quaisquer consequências não óbvias de certas ações.

24
Cancelar
Ação Sugerida

Texto de alerta

Um alerta possui texto primário e secundário

O texto primário contém um breve resumo da situação e sugere uma determinada ação. Este texto deve usar a classe CSS primary.

O texto secundário fornece uma descrição mais detalhada da situação e descreve os eventuais efeitos secundários das ações disponíveis. É importante notar que um usuário vai precisar apenas do texto primário para tomar uma decisão. Assim, o texto secundário só será necessário para fornecer esclarecimentos. Este texto deve ser colocado abaixo do texto primário com uma linha de diferença, usando tamanho e espessura de fonte padrões.

Faça tanto o texto selecionável primário e secundário. Isto torna mais fácil para o usuário copiar e colar o texto para outra janela, como uma mensagem de e-mail.

Ordem dos botões

"OK" não está Ok

Quando apresentar um diálogo a um usuário, sempre use nomes explícitos para ações como "Salvar..." ou "Desligar". Considere como um "OK" permite aos usuários continuarem sem entender a ação que estão autorizando. Nem todos os usuários vão ler a pergunta ou as informações apresentadas a eles em um diálogo. Usar nomes específicos para ações dificultará a escolha de uma ação não-intencional pelo usuário e pode até mesmo encorajá-los a ler as informações apresentadas antes de tomar uma decisão.

Diálogos de preferências

Diálogos de preferências devem ser Transientes, mas não Modais. Quando um usuário faz uma mudança em um diálogo de preferência, a mudança deve ser imediatamente visível na interface de usuário. Se o diálogo é modal, o usuário pode ser impedido de ver (e, especialmente, de interagir com) a mudança. Isso significa que terão que fechar o diálogo, avaliar a mudança, e então possivelmente reabrir o diálogo. Ao fazer esse diálogo transiente, mantemos o diálogo no topo para acesso fácil, mas também deixamos que o usuário avalie e possivelmente reverta a mudança sem ter que fechar e reabrir o diálogo de preferência.


Veja também:

  1. Why Por que os Botões 'Ok' em Caixas de Diálogo Funcionam Melhor à Direita por UX Movement
  2. Por Que o Botão Ok Não É Ok por UX Movement
  3. Devo usar Sim/Não ou Ok/Cancel na minha caixa de mensagem? em UX StackExchange
  4. Onde Colocar Ícones Próximos aos Rótulos de Botão por UX Movement

Popovers

Popovers são dialogos contextuais. Eles mostram conteúdo momentâneo, diretamente relacionado ao que foi clicado e se fecha quando for clicado fora dele, menus por exemplo.

Um popover deve ser usado quando um usuário quer realizar uma operação rapidamente sem sair da UI principal. Alguns exemplos de onde popovers podem ser usados são adicionar um contato de um email, adicionar um favorito em um navegador ou mostrar downloads ou arquivos transferidos.

Popovers não devem ser usados quando se quer mostrar apenas uma lista de itens simples; nesse caso use um menu. Da mesma forma, não use um popover se o usuário iŕa gastar mais do que alguns segundos nele; nesse caso use um dialogo. Lembre-se que popovers são contextuais e devem se relacionar diretamente com o elemento da UI da qual ele se originou.

Barras de Ferramentas

Uma Barra de Ferramentas é útil para fornecer aos usuários acesso rápido a funções mais usadas em um aplicativo. Além de Botões, uma Barra de Ferramentas é um dos elementos de interface de usuário mais frequentemente usados. Ela pode parecer um simples contêiner, mas é importante que seu uso e sua organização se mantenham consistentes.

Ordernar Itens da Barra de Ferramentas

Itens da Barra de Ferramentas devem ser organizados com os objetos mais significativos à esquerda e o menos significativo à direita, com o Menu da Aplicação sempre na extremidade direita da Barra de Ferramentas. Se você tiver muitos itens na barra de ferramentas pode ser adequado dividi-los em grupos com espaços entre cada grupo. Tenha em mente que quando é visualizado com idiomas RTL, o layout da sua barra de ferramentas será invertido.

UI Toolkit Elements

elementary OS uses consistent user interface (UI) elements to bring a unified and predictable experience to users, no matter what app they're using. When used properly, this ensures a small (or nonexistent) learning curve for your app.

Conceitos Widget

Antes de entrar em todos os widgets disponíveis no elementary, precisamos cobrir alguns conceitos básicos que se aplicam a todos os widgets. Empregando esses conceitos corretamente irá criar uma experiência mais transparente para seus usuários e ajudá-lo a evitar relatórios de bugs!

Controles que não fazem nada

Um erro muito comum para os desenvolvedores a fazer é criar controles que aparentemente não fazem nada. Tenha em mente que queremos apresentar um ambiente onde os usuários se sentem confortáveis explorar. Um usuário curioso irão interagir com um controle esperando que haja alguma reação imediata. Quando um controle aparentemente não faz nada, isso cria confusão e pode ser assustador (Pense, "uh-oh, eu não sei o que aconteceu!"). Em alguns casos, os controles que não fazem nada são simplesmente lixo e adicionar complexidade desnecessária para sua UI.

Como exemplo, imagine o botão de "limpar" em campos de pesquisa. Esse botão só deve aparecer quando é relevante e necessário. Clicar nesse botão quando o campo já estiver limpo basicamente não faz nada, sendo completamente inútil.

Sensibilidade

Às vezes não faz sentido que o usuário interaja com um widget antes de algum pré-requisito ser cumprido. Por exemplo, não faz sentido deixar o usuário clicar no botão "Avançar" em um navegador a menos que haja histórico de avanço disponível. Nesse caso, você deve desativar o botão "Avançar" ou um usuário pode clicar nele, esperando um resultado, e ficar confuso quando nada acontecer.

Geralmente é melhor para fazer um widget insensível do que escondê-lo completamente. Fazendo um widget insensível informa ao usuário que a funcionalidade está disponível, mas só depois de uma determinada condição seja atendida. Escondendo o widget dá a impressão de que a funcionalidade não está disponível em todos os ou pode deixar um usuário se perguntando por uma característica, de repente, "desapareceram".

Widgets escondidos

Quando um widget só faz sentido em um determinado contexto (e não como um indicador de uma ação a ser executada), por vezes, faz mais sentido para escondê-lo. Tome requisitos de hardware por exemplo: Não pode fazer sentido para mostrar as opções de multi-display, se o sistema só tem uma única tela. Fazer opções com diversos monitores insensível não é realmente uma dica útil neste sistema. Outra isenção a esta regra é um widget que um usuário irá procurar somente no contexto, como o exemplo claro botão acima. Finalmente, tenha em mente que os itens insensíveis ainda será reconhecido por leitores de tela e outros tecnologia assistiva, enquanto os widgets ocultos não.

Espaçamento

Alinhamento


Veja também: Label Formulário de Proximidade: alinhado à direita é mais fácil digitalizar por Movimento UX

Barras de Informações

Infobars fornecer informações e ações contextuais para o usuário com diferentes níveis de gravidade.

É importante para determinar a gravidade ou o tipo de infobar de usar. Existem quatro tipos de infobars disponíveis:

Tela de boas vindas

A Tela de Boas-Vindas é uma maneira amigável de ajudar os usuários a começar com seu aplicativo.

Uso

Tipicamente uma Tela de Boas-Vindas é usada para apps como o Noise ou Scratch onde você deve importar ou criar uma biblioteca de objetos antes de interagir com eles. Isso proporciona aos seus visitantes um caminho claro para começar e aponta quaisquer medidas imediatas que devem ser tomadas antes de seu aplicativo tornar-se útil.

Se seu app permite aos usuários limpar sua biblioteca, certifique-se de que ele retorna para a Tela de Boas-Vindas em vez de para uma lista vazia.

Marcação

A tela de Boas Vindas consiste de dois conjuntos de etiquetas:

Iconografia

Juntamente com cada ação está um ícone que ajuda a rapidamente visualizá-la. A maior parte do tempo esses serão ícones de ação, mas você pode usar icones de lugar quando importando ou definindo um local e até icones de aplicativos se precisar abrir um utilitário de configuração.

Lista de recursos

Uma lista de recursos pode ser usada como uma forma de navegação. Lista de recursos são úteis para mostrar diferentes locais, marcadores ou categorias em seu aplicativo.

Seções

Uma lista de recursos pode ser separada em seções expansíveis diferentes, cada uma com seu próprio cabeçalho. Por exemplo, um gerenciador de arquivos pode ter uma seção de locais favoritos, uma seção para dispositivos de armazenamento conectados ao computador e uma seção para locais de rede. Essas seções ajudam a agrupar itens relacionados na lista de recursos e permite ao usuário esconder seções sem uso.

Se possível evite aninhar seções dentro de uma lista de recursos; se você tiver de fazer isso, é melhor repensar suas seções.

Hierarquia

Hierarquia é importante com listas de origem, tanto dentro do próprio widget e no âmbito mais amplo do seu aplicativo.

As seções presentes nas listas deverão ser apresentadas de acordo com a sua importância, com as mais importantes em mente. Se está com dificuldade em decidir quais as importâncias relativas de cada seções, pensa em qual o usuário deverá usar mais vezes. Arrumar as seções desta forma garanta que as mais importantes estão sempre visíveis, mesmo que o espaço seja curto para se verem todas as seções, e as menos importantes estarão disponíveis após o scroll.

A source list goes at the left side of a window (or right side for right-to-left languages). Because the user reads in this direction, the sidebar is reinforced as being before (and therefore at a higher level than) the app's contents.

Botões

Buttons are an incredibly important widget to understand since your app will undoubtedly contain them.

Botões de Ferramentas

Marcação

Botões são quase sempre apenas ícones e não fornecem uma borda. Eles não devem precisar de uma etiqueta para ser compreendido.

Dicas

Todos os botões devem ter dicas, desde que não contenham etiquetas.Assistentes para deficientes também devem entender os ícones. Dicas devem ser feitas em Forma de frase.

Como etiquetas em botões de texto, uma dica deve descrever claramente o que irá acontecer quando o botão for pressionado.

Botões de Texto

Marcação

Textos em botões devem ser escritos em Caixa de Título.

Tal como os itens dos menus, as etiquetas dos Botões deverão consistir numa ação ou localização, mas não um estado. Certifique-se que a etiqueta descreve claramente o que vai acontecer quando o botão for pressionado.

"Remover conta", "Transferir para Laptop do Jim", e "Importar 20 Sons" são bons títulos.

"OK", "Obtenha mais armazenamento!", e "Bateria Baixa" não são bons rótulos para botões. O rótulo "Obtenha mais armazenamento!" possui capitalização incorreta e pontuação desnecessária. Os outros dois rótulos não indicam quais serão os resultados de um clique no botão.

Dicas

Sendo que botões tem textos limpos e diretos, normalmente é desnecessário o uso de tooltip.

Botões Conectados

Uso

Botões Interligados são usados para agrupar ações que são semelhantes em natureza ou mutamente exclusivas. Por exemplo, poderão agrupar opções de texto como Negrito, Itálico e Sublinhado, ou podem ser usadas de forma mutamente exclusiva como "Grade, Lista, ou Vista de Coluna".

Marcação

Botões de link nunca devem contem icones coloridos. Apenas ícones simbólicos de 16px OU texto. Não misture ícones e texto.


  1. Porque o botão OK não está mais OK (em inglês) por UX Movement
  2. Devo usar Sim/Não ou Ok/Cancel na minha caixa de mensagem? em UX StackExchange

MenuDeApps

O AppMenu é um menu adicional que se abre ao clicar no ícone da roda dentada no extremo direito da barra de ferramentas. Providencia entradas de menu relevantes em vez do mais tradicional menu "File, Edit, View..." .

Uso

Deverá avaliar se o seu aplicativo necessita deste widget. Apesar da maioria dos apps terem um, o seu aplicativo pode não necessitar do mesmo.

Quando adicionar itens ao menu do seu aplicativo, considere o seguinte:

Campos de Pesquisa

Aplicativos que permitem pesquisar e filtrar seu conteúdo devem incluir um campo de pesquisa no lado direito da barra de ferramentas. Por ser a localização padrão, o usuário sempre vai olhar pra esse certo lugar para ver se o app suporta pesquisas ou não. O Gtk+ fornece um widget prático e poderoso para este propósito, chamado Gtk.SearchEntry.

A Diferença entre Pesquisar e Localizar

A pesquisa serve para filtrar o conteúdo de uma biblioteca (de música ou vídeos, p. ex.), onde serão exibidos apenas os itens correspondentes. A pesquisa é geralmente iniciada ao digitar em qualquer lugar na tela de uma biblioteca.

A função Localizar serve para destacar instâncias correspondentes a um pequeno trecho de texto em um editor de texto, uma página da web ou no Terminal, por exemplo. É ativada por um atalho de teclado (Ctrl+F) ou por um ícone de pesquisa. A barra de buscas surge debaixo da headerbar com ações relevantes como localizar próximo, localizar anterior, destacar todas, etc. A barra pode também conter outras ações relevantes, como substituir ou ir para linha.

Comportamento

Se for possível incluir a funcionalidade de pesquisa no seu app... inclua!. Qualquer lista ou representação de múltiplas entidades de dados deve ser pesquisável usando um campo de pesquisa que siga as seguintes regras:

Marcação

Os campos de pesquisa deverão conter uma dica textual que descreva o que vai ser pesquisado. Pode definir este valor usando a propriedade "placeholder_text".

A maioria dos campos de pesquisa devem usar o formato "Pesquisar OBJETOS ", onde OBJETOS é oque deve ser pesquisado, como Contatos, Contas, etc.

Se o campo de pesquisa interage com alguma serviço, o texto de dica deve ser o nome desse serviço, como "Google" ou "Yahoo!"

Checkboxes & Switches

Checkboxes

Checkboxes apresentam uma forma do usuário selecionar itens de uma lista.

Uso

Use checkboxes quando os usuários estiverem fazendo uma seleção de itens. Certifique-se que o usuário pode mudar o estado do checkbox clicando na label que o acompanha.

Marcação

Labels associados a checkboxes são normalmente substantivos ou frases nominais.

Switches

Switches apresentam uma forma do usuario ativar/desativar certas características.

Uso

Não use interruptores para incluir itens relacionados como parte de uma lista, usa uma Caixa de Seleção. Pensa no interruptor como atuante em serviços independentes, e as caixas de seleção para incluir objetos numa lista. Isto é uma distinção importante a fazer.

Nota que a opção "gravar a partir do microfone" é uma boa candidata para um interruptor. Está a ativar ou desativar o serviço de gravação.

No entanto, se há duas opções "Gravar os sons de sistema" e "Gravar a partir do microfone" já estás a lidar com uma lista de itens relacionados, e que deverão ser incluídos como partes de um serviço de gravação (cujo estado de on e off é independente do tipo de serviços incluídos). Neste caso, uma Caixa de seleção é mais apropriado para apresentar estas duas opções.

Marcação

Sempre que possível chame diretamente o nome do serviço sobre o qual estás a actuar. Não use palavras que descrevam o estado que o widget está a descrever, como por exemplo "ativar multitoque", "Use multitoque" ou "Desativar Multitoque". Isto pode gerar uma situação confusa. Em vez disso, use apenas o nome e escreve "Multitoque".


Ver também: 3 maneiras de Criar Caixas de Seleção, Botões de Rádio mais fáceis de clicar por UX Movement

Cadernos

Cadernos são um tipo de widget que permitem aos aplicativos mostrar uma de múltiplas páginas (também referido coloquialmente como "barra de abas").

Cadernos estáticos

Um caderno estático é um conjunto de abas fixas, normalmente encontradas em preferências e telas de configuração. As abas aparecem como botões ligados centralizados no topo da área de conteúdo. Um caderno estático normalmente deve conter de duas à cinco abas.

Cadernos dinâmicos

Um Bloco de Notas Dinâmico é uma forma de se disponibilizar a gestão desta funcionalidade ao usuário final, normalmente visto nos navegadores de internet. Os separadores aparecem "agarrados" a barra de ferramentas na sua barra específica, sobre o conteúdo relevante. Estes separadores podem ser reordenados e fechados pelo usuário, existindo o botão de "novo separador" no extremo esquerdo desde widget.

Iconografia

A iconografia é uma parte chave do elementary OS. Os ícones são a principal componente da Interface que o usuário irá usar; é o que dá vida ao sistema, e permite ao cérebro humano reconhecer o que está vendo.

Forma

O seu ícone deveria ter uma forma distinta / silhueta para melhorar o seu reconhecimento. Esta forma não deve ser muito complicado, mas o ícone não deveria ser sempre um rectângulo arredondado.

Ícone do Diálogo de AvisoÍcone de ChatÍcone de FotosÍcone de VídeosÍcone de Contas OnlineÍcone de Terminal

Metáforas

Se você está criando um ícone para um equipamento físico ou tipo de arquivo (como os do MimeType ou Dispositivo), a sua forma é normalmente a representação visual dos seus equivalentes no mundo real. Por exemplo o ícone da câmera fotográfica, é uma câmera fotográfica estilizada.

Ícone de CameraÍcone de Disco RígidoÍcone de MouseÍcone de PacoteÍcone de Texto HTMLÍcone de Computador

Ícones de Ação

Ícones de ação são gráficos usados para representar ações de usuário. Ícones de ação são mais vulgarmente encontrados nas barras de ferramentas das apps, mas podem ser encontrados por toda a parte no SO.

Ícone de AnteriorÍcone de PróximoÍcone de Exportar DocumentoÍcone de ImpressãoÍcone de SalvarÍcone de DeletarÍcone de CortarÍcone de DesfazerÍcone de InverterÍcone de PlayÍcone de nova TagÍcone de Menu

Se o seu aplicativo tem uma ação que pode ser descrita por um ícone de ação existente do sistema, use esse ícone. Isto garante uma experiência de utilização consistente e ajuda o utilizador no reconhecimento de funções comuns.

Se o seu aplicativo tem uma ação única não facilmente descrita por um ícone existente, pode ter que criar o seu próprio ícone. Segue o aspecto e aparência dos ícones de sistema existentes e instala o ícone juntamente com o seu aplicativo.

Tamanho dos ícones

O elementary OS usa seis dimensões de ícones e é sempre necessário incluir as seis dimensões como parte integrante da sua aplicação.

Ícone de Terminal em 16 pixelsÍcone de Terminal em 24 pixelsÍcone de Terminal em 32 pixelsÍcone de Terminal em 48 pixelsÍcone de Terminal em 64 pixelsÍcone de Terminal em 128 pixels
16 24 32 48 64 128
Ícone de Terminal em 128 pixels
128

Faça cada ícone para o tamanho em que ele deve ser visto. Em outras palavras, não faça apenas um ícone e redimensione-o para outros tamanhos. Você adquire um resultado melhor quando cada ícone é feito individualmente. Para mais informações sobre esta prática, chamada de "pixel-fitting", e sua importância, recomendamos a leitura de Pixel-fitting, escrito por Dustin Curtis,

Paleta de cores

Color, don't be afraid to use it! Many of the elementary OS icons use vibrant colors; it's best to reserve muted tones and greys for boring system icons.

Ícone de EmailÍcone de Leitor RSSÍcone de navegador webÍcone de FotosÍcone de RedeÍcone de Calendário

As cores têm um sentido, uma conotação que deve conhecer. o vermelho, por exemplo, está normalmente associado a erro ou perigo e o laranja com aviso. Mas pode usar esta informação para ajudar a passar o significado do ícone, como por exemplo a cor verde num ícone para avançar.

Ícones Simbólicos

Ícones Simbólicos são ícones comuns do sistema, que simbolizam arquivos, dispositivos ou diretórios, além de serem usados para representar ações como copiar, colar e salvar.

Cada ícone simbólico é uma forma reduzida de seu correspondente colorido. Este design minimalista garante legibilidade e clareza mesmo em tamanhos pequenos.

Ícone colorido x simbólico

Ícones Coloridos X Simbólicos

Ícones coloridos e simbólicos não podem ser usados de qualquer forma: ambos têm suas próprias situações de uso apropriadas.

Ícones coloridos ficam melhor em:

Ícones simbólicos ficam melhor:

Composição

There are three aspects to note when designing an elementary OS icon:

Composition breakdown of elementary OS Videos icon Composition breakdown of elementary OS Terminal icon

Mantendo estas linhas em mente ao projetar, significa que você pode colocar elementos ao longo deles, por isso ícones aparecem mais consistente quando colocados juntos. Por exemplo, observe como alguns elementos, tanto no ícone Terminal e Vídeos acima referem-se a linha média.

Padrão de medidas

Se você está projetando um ícone em forma de quadrado, como o Terminal visto de acima, então considere o uso dessas medidas comuns (em pixels) para cada ícone.

Tamanho do canvas Linha base x-Height Linha de altura média
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

Exceções

No entanto, há exceções. Muitos ícones (especialmente ícones mimetype) têm elementos ascendentes e descendentes, que são os elementos que se estendem além da linha de base e linha X-altura (mostrado aqui em laranja.)

Composition exception example in elementary OS Video icon Composition exception example in elementary OS Terminal icon

Componentes Rounder geralmente requerem algum superação, para compensar a ilusão de óptica que os faz parecer menor do que os seus homólogos retangulares.

Esboços & Contraste

All elementary OS icons have a thin outline (stroke) to improve their contrast. The width of this stroke is one pixel for all icons, at every size. The color of the outline is a darker variant (30% darker) of the primary color of the icon. For instance, in the calendar icon below, the green header has a stroke of a darker green.

Example of contrast in elementary OS Calendar icon Exemplo de contraste no ícone de configurações do elementary

Para melhorar o constraste, os strokes são também semi-transparentes. Isto garante que os ícones aparecem nítidos numa grande variedade de fundos. Do mesmo modo, se o elemento for quase branco, esta linha funciona como uma borda que contém, e não sobrepõe, o seu elemento. Veja o exemplo acima para verificar como deve ficar.

Sombras & Destaques

If you picture an icon sitting on a shelf, facing you, with a light source above it, you may see a small fuzzy shadow near the bottom. Also, since the edges of an object tends to reflect more light due to your position relative to it and to the light source, they will have a highlight. Both these effects are something elementary OS icons emulate in their design to lend them a degree of realism.

Destaques de Bordas

Para aplicar o efeito de highlight nos vértices no seu ícone, desenhe uma linha interior subtil de 1 pixel como marcação. Este outline é mais claro no topo e no fundo do que nas laterais.

Edge highlight example in elementary OS Music icon

Sombra projetada

Para desenhar a sombra começa por desenhar um rectângulo. Preencha-o com um gradiente linear que é prependicular a margem inferior do ícone. Este gradiente tem três paragens, a primeira e última têm zero de opacidade. Atribua depois uma opacidade de 60% a esta forma.

Em seguida, crie dois rectangulos de dimensão inferior para as pontas do maior. Encha cada um com um gradiente identico ao anterior, mas use o radial. Centra verticalmente este gradiente no meio do gradiente anterior, de forma a consegua uma continuidade entre todas as peças -veja o exemplo abaixo-. Ambos estes rectângulos devem também ter uma opacidade de 60%.

Sombra Pictogramada

Se o seu ícone tem um pictograma, como por exemplo o triângulo do botão de play do ícone seguinte, pode atribuir uma sombra projetada para que sobresaia do background do ícone.

Para fazer isto, duplique o pictograma, preencha-o de preto sólido, e altere a opacidade para 15%. Em seguida desloque-o 1 pixel para baixo e coloque-o por debaixo do pictograma original. Crie uma cópia desta sombra é dê um stroke de 1 pixel (também preto) e ajuste este elemento para 7% de opacidade.

Ícones de Materiais

Tem a liberdade em adiconar brilho (highlights extra) ao seu ícone mas isto só é uma boa ideia se esta a emular uma superfície que seja mais reflectiva no original (plástico, vidro, etc.). por exemplo uma folha de papel não tem brilhos nem reflexos, logo um ícone que a tome como base também não os deve ter.

Fazer e Não Fazer

Abaixo estão alguns exemplos de "fazer e não fazer" a considerar ao criar ícones para o seu app.

Texto

Although elementary OS primarily uses graphics as a means of interaction, text is also widely used for things like button labels, tooltips, menu items, dialog messages, and more. Using text consistently and clearly both in terminology and format is an extremely important part of designing your app and helps add to the overall cohesiveness of the elementary OS platform.

Estilo de escrita

Utilize as regras a seguir para manter seu texto compreensível e consistente.

Seja Breve

Não entregue ao usuário uma quantidade enorme de texto para ler; uma frase comprida pode desencorajar os usuários de a ler. Entregue sim texto curto e conciso.

Pense Simples

Assuma que o usuário é inteligente, mas não técnico. Evita palavras compridas ou estranhas e centre-se em usar verbos simples, comuns, nomes e adjetivos. Nunca use palavriado técnico.

Ir para a última linha

Coloca a informação mais relevante no início do texto. Se o usuário parar de ler, pelo menos fica com a memória do mesmo.

Não Se Repita

Repetição pode ser irritante e adiciona tamanho desnecessário à sua mensagem.

Use Hierarquia Visual

Hierarquia visual ajuda os usuários a ler e compreender o seu texto, bem como a reconhecer o que é mais importante. Use correctamente cabeçalhos e os outros estilos.

Idioma

While much of elementary OS is developed in English, there are many users who do not know English or prefer their native language. While putting text into your app, keep the following in mind:

Capitalização

Todos os componentes de interface de usuários textuais como etiquetas, botões e menus devem usar um de dois estilos de capitalização: de frase ou de título.

Caso de sentença

Capitalização de Frase significa que usas maiúsculas como uma escrita/frase normal.

Apenas a primeira letra da frase e dos nomes próprios é escrita em maiúsculas. Usado para etiquetas e texto descritivo.

Título casual

Título casual significado que você capitaliza como um título de livro ou artigo.

Capitaliza a primeira e última palavra. Todos os nomes, pronomes, adjetivos, verbos, advérbios, e conjunções (como, porque, apesar) são capitalizadas. Usado para títulos, botões, menus e na maioria dos outros widgets.

Notas/Exceções

Os nomes próprios e marcas devem ser sempre escritos de acordo com as suas normas; isto significa que, Google, por exemplo, deve ser sempre escrito como "Google", elementary deverá aparecer sempre "elementary" e MPEG deverá ser sempre "MPEG". Se tem dúvidas como um nome deve ser escrito, procure as normas gráficas dessa marca.

Pontuação

Tipografia adequada é importante em todo elementary OS. Não apenas por consistência dentro do OS, mas para seguir convenções adequadas e nos mostrar como uma plataforma série e profissional.

Previna Erros Comuns

Hifens e traços

Hífen (-)

Utilize \u2010 em seu código.

Meia-risca (–)

Utilize \u2013 em seu código. Usado para:

Travessão (—)

Utilize \u2014 em seu código. Usado para:


Se estiver em duvida, use Butterwick's Practical Typography como referência.

Essas regras se aplicam à língua inglesa; outras línguas podem ter suas próprias convenções que devem ser descritas por tradutores.

Utilizando Reticências

O personagem de reticências (...) é usado na interface por duas razões principais: passando para o usuário uma informação complementar necessária, permitindo que o usuário saiba que o texto foi encurtado.

Informações adicionais

Uma elipse deve ser usado para permitir que um usuário sabe que mais informações ou uma ação adicional é necessária antes de sua ação pode ser executada. Normalmente, isso significa que o usuário deve esperar um novo elemento de interface para aparecer como uma nova janela de diálogo, barra de ferramentas, etc em que devem entrar obter mais informações ou fazer uma seleção antes de completar a ação pretendida. Esta é uma distinção importante porque um usuário normalmente deve esperar uma ação instantânea a partir de botões e itens de menu enquanto tenha umcomportamento alternativo. Epecificamente, uma elipse deve ser usado quando há ação associada:

Texto encurtado

Reticências devem ser usadas para encurtar textos que não cabem em um lugar específico. Por exemplo, se o nome de uma playlist é maior do que o espaço disponível na barra lateral, trunque-o e use reticências para comunicar sua truncagem. Existem duas maneiras de se usar reticências ao encurtar textos:

No caso de dúvida o melhor será usar a omissão central, já que mantém o princípio e o fim do texto intactos. Também é importante não publicares um app com muito texto omitido. A regra ótima é: só deves omitir o texto como resultado de uma acção do usuário, que quer redimensionar uma área, que quer escrever texto pessoalmente.

Quando não usar reticências


Certifique-se de usar o caractere próprio de reticências (...) em vez de caractere três pontos (.).

Nomeando itens do menu

Os itens de menu devem ter nomes que são locais ou ações, nunca descrições. Certifique-se de itens de menu são concisas, mas também descrever completamente a ação que será executada quando eles são clicados.

"Encontrar Pagina ..." é aceitável, uma vez que claramente descreve a ação que será executada quando o item é clicado. "Software Up to Date" não é aceitável. O que acontece se eu clicar este item? Onde ele vai me levar? O que vai fazer? O resultado é incerto.