O projeto de usabilidade GNOME
2002-2012
Calum Benson, Adam Elman, Seth Nickell, colin z robertson
03/10/2013
2.2.3

Este documento diz como criar aplicativos que pareçam adequadas, comportem-se corretamente, e se encaixem como um todo na interface de usuário do GNOME. É escrito para designers de interfaces, artistas gráficos e desenvolvedores de software que criarão aplicativos para o ambiente GNOME. Tanto recomendações específicas em como fazer uso eficaz dos elementos da interface, e a filosofia e os princípios gerais de design por trás da interface do GNOME serão abordados.

Permissão concedida para copiar, distribuir e/ou modificar este documento sob os termos da licença de documentação livre GNU (GNU Free Documentation License), Versão 1.1 ou qualquer versão mais recente publicada pela Free Software Foundation sem Seções Invariantes, Textos de Capa Frontal, e sem Textos de Contracapa. Você pode encontrar uma cópia da licença de documentação livre GNU (GNU Free Documentation License) visitando o site ou no escrevendo para: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Vários dos nomes usados por companhias para distinguir seus produtos e serviços são marcas registradas. Onde esses nomes aparecem em qualquer documentação do GNOME, e essas marcas são feitas cientes para os membros do projeto de documentação do GNOME, os nomes foram gravados em caixa alta ou iniciados em caixa alta.

# Diretrizes de interface humana do GNOME 2.2.3

Georges Neto
georges.stavracas@gmail.com
2013
2014.
Georges Neto
Enrico Nicoletto
liverig@gmail.com
2013.
Enrico Nicoletto

## O que há de novo?

Esta seção destaca mudanças recentes às DIH que podem afetar seu aplicativo.

As seguintes mudanças foram feitas nas DIH v.2.2.3:

- Referências atualizadas para acessibilidade, documentação e projetos freedesktop.

As seguintes mudanças foram feitas nas DIH v.2.2.2:

- Adição de em relação a relevância deste guia para o GNOME 3.

As seguintes mudanças foram feitas nas DIH v.2.2.1:

- Menção em que indicadores de progresso locais são preferíveis à janelas de diálogo modais de progresso.

- Substituição da orientação em sobre janelas de progresso tendo o mesmo título do seu texto primário, o que leva à redundância desnecessária. A recomendação agora é que títulos de janelas de progresso devem resumir a operação total.

As seguintes mudanças foram feitas nas DIH v.2.0:

Diretrizes novas ou revisadas foram adicionadas à essas seções nas DIH v.2.0:

As seguintes mudanças de terminologia foram introduzidas no HIG v2.0:

- "Menu de opções" agora são chamados "Listas suspensas"

- "Caixas de combinação" agora são chamadas "Caixas de combinação suspensas"

## Introdução

Este documento diz como criar aplicativos que pareçam adequadas, comportem-se corretamente, e se encaixem como um todo na interface de usuário do GNOME. É escrito para designers de interfaces, artistas gráficos e desenvolvedores de software que criarão aplicativos para o ambiente GNOME. Tanto recomendações específicas em como fazer uso eficaz dos elementos da interface, e a filosofia e os princípios gerais de design por trás da interface do GNOME serão abordados.

Estas diretrizes são destinadas a ajudá-lo a projetar e escrever aplicativos fáceis de utilizar e consistentes com o ambiente de trabalho GNOME. Seguir estas diretrizes trará muitos benefícios:

- Usuários aprenderão a usar seu programa mais rápido, pois os elementos de interface irão parecer e se comportar do modo que estão acostumados.

- Usuários novatos e avançados semelhantemente serão capazes de realizar tarefas rápida e facilmente, pois a interface não será confusa ou tornará as coisas difíceis.

- Seu aplicativo terá uma aparência atraente que se encaixa com o resto da área de trabalho.

- Seu aplicativo continuará com uma boa aparência quando usuários mudarem temas, fontes e cores do área de trabalho.

- Seu aplicativo será acessível para todos os usuários, incluindo aqueles com deficiências ou necessidades especiais.

Para ajudá-lo a alcançar essas metas, estas diretrizes cobrirão elementos básicos da interface, como usá-los e colocá-los juntos eficientemente, e como fazer seu aplicativo se integrar bem com o ambiente de trabalho.

As recomendações aqui foram construídas em aspectos de design que funcionaram bem em outros em outros sistemas, incluindo Mac OS, Windows, Java e KDE. Ao mesmo tempo, retêm um sabor único do GNOME.

### Lembre-se...

Seguir as diretrizes fará seu trabalho mais fácil, e não mais difícil!

## Aplicabilidade ao GNOME 3

Esta versão das diretrizes de interface humana foi escrito para designers e desenvolvedores de aplicativos GNOME 2. Esse foco é refletido nos conselhos oferecidos, e nas ilustrações acompanhantes.

Visto que muitos deles aplicam-se igualmente ao GNOME 3, entretanto, você pode e deve continuar a seguir a maioria destes princípios e diretrizes de usabilidade no seu aplicativo GNOME 3.

Um documento atualizado de diretrizes de interface humana focando no GNOME 3 será lançado no devido momento. Até lá, você pode encontrar algumas diretrizes específicas do GNOME 3 na página Diretrizes do GNOME Shell.

O projeto de usabilidade GNOME, março de 2011

## Princípios de usabilidade

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.

### Projete para as pessoas

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:

1. quem são seus usuários

2. o que deseja possibilitá-los a fazer

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.

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

### Não limite sua base de usuários

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

#### Acessibilidade

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

- 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

- 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

- Usuários com movimentos limitados podem não ser capazes de utilizar seu aplicativo se você não fornecer equivalentes do teclado para comandos

Seu aplicativo também deve ser utilizável com interfaces de voz, leitores de tela como Orca, 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.

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 Projeto de acessibilidade GNOME.

#### Internacionalização e localização

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.

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 página inicial do projeto Pango (Pango é a biblioteca do GNOME para renderizar texto internacionalizado), a página de traduções do GNOME e a página do projeto de tradução de GNOME.

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.

Exemplos de elementos que é melhor evitar por essas razões incluem:

- Figuras de bandeiras ou dinheiro

- Mapas mostrando limites políticos ou nomes controversos de locais

- Listas de países ou cidades em ordem não-alfabética (a menos que seja especificamente solicitado ou requerido pelo contexto)

- Ícones representando animais

- Ícones representando apenas mãos ou pés

### Crie uma correspondência entre seu aplicativo e o mundo real

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

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:

- uma imagem de uma pasta de arquivos sugere um contêiner no qual documentos podem ser colocados

- um cesto de lixo sugere um contêiner no qual itens podem ser colocados quando não são mais necessários

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.

### Faça seu aplicativo consistente

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.

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.

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 Desfazer 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 Desfazer do menu.

### Mantenha o usuário informado

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.

É crítico que o comentário (feedback) seja correto e preciso. 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.

Veja e para mais informações sobre retorno.

### Mantenha simples e belo

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.

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.

Veja e para mais informações sobre projetar a aparência visual de seu aplicativo.

### Coloque o usuário no controle

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 para mais informações sobre modos.

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

### Perdoe o usuário

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.

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.

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.

### Forneça manipulação direta

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.

Veja para mais informações sobre manipulação direta.

## Integração com o ambiente de trabalho

Há dois elementos para uma integração básica com o ambiente de usuário do GNOME.

1. Coloque uma entrada para seu aplicativo no menu Aplicativos. Este é o mecanismo primário pelo qual os usuários descobrem e executam aplicativos.

2. Caso seu aplicativo possa abrir e salvar arquivos, coloque uma entrada para esses tipos de arquivos no banco de dados do aplicativo e no banco de dados de tipos de documento (MIME). Isso permite que o gerenciador de arquivos e outros aplicativos automaticamente executem seu aplicativo quando encontram arquivos que seu aplicativo pode manipular.

Não adicione lançadores ou outros ícones na área de trabalho quando seu aplicativo é instalado. A área de trabalho é o espaço do usuário, e é reservado para ícones que ele explicitamente solicite ou adicione.

### Colocando entradas no menu Aplicativos

#### O menu Aplicativos

Captura de tela do menu Aplicativos aberto no painel de menus do GNOME

O menu Aplicativos, o qual aparece no painel no topo da tela por padrão, é o mecanismo primário pelo qual os usuários descobrem e executam aplicativos. Você coloca entradas nesse meno ao instalar um arquivo `.desktop` apropriado.

O menu é arranjado em um conjunto de categorias, como Acessórios e Jogos. Aplicativos são colocados em categorias particulares pelo conjunto de palavras-chave que incluem em seu arquivo `.desktop`.

#### Diretrizes

- Atribua a seu aplicativo apenas uma categoria no menu Aplicativos

- Para suítes de aplicativos que envolvem sub-aplicativos menores em uma única janela, como Evolution ou OpenOffice.org, adicione um item de menu para cada sub-aplicativo. Por exemplo, o e-mail, o calendário e a lista de tarefas no Evolution devem ter cada um seu próprio item no menu.

Detalhes técnicos podem ser encontrados nas especificações de menu e de entradas da área de trabalho em freedesktop.org.

#### Nomes dos itens de menu

##### Inclua uma descrição funcional no nome do menu

No nome do item de menu, inclua uma descrição da funcionalidade além do próprio nome do aplicativo. Isso é especialmente útil para usuários novatos, e para usuários de sistemas onde inúmeros aplicativos estão instalados por padrão. Usuários são mais suscetíveis a encontrar seu aplicativo se o nome que aparece no menu inclui uma descrição de sua funcionalidade.

Por exemplo, um teste de usuários do sistema Athena do MIT revelou que usuários tiveram dificuldade de encontrar o gerenciador de arquivos porque não eram familiarizados com o nome "Nautilus". O item de menu não ajudou os usuários porque eles não associaram a palavra "Nautilus" com o conceito "gerenciador de arquivos". Esse é um exemplo de como não utilizar a linguagem do usuário. Veja para mais informações neste tópico.

###### Incluindo descrições funcionais nos nomes do menu

Item de menu original | Item de menu revisado
--- | ---
Epiphany | Navegador web Epiphany

##### Coloque apenas informações úteis no nome do menu

Não inclua palavras como "GNOME", "Sistema de janelas X", "GTK+" ou outros detalhes da plataforma no nome do menu Aplicativos. O usuário provavelmente já sabe qual plataforma que estão usando, e caso não saibam, nomes de aplicativos não são o lugar correto para informá-lo.

###### Removendo informação não essencial do nome do menu

Item de menu original | Item de menu revisado
--- | ---
Visualizador de imagens do GNOME | Visualizador de imagens
Editor de blog em GTK | Editor de blog

Não inclua detalhes técnicos quando o usuário não precisa conhecê-los, ou pode inferí-los do contexto. Evite jargão técnico a não ser que o aplicativo seja usado apenas por uma audiência técnica.

Por exemplo, quando tanto um cliente e um servidor de algo são listados nos menus, remova a palavra "cliente" do nome do menu do cliente.

###### Removendo jargão técnico dos nomes do menu

Item de menu original | Item de menu revisado
--- | ---
Cliente de batalha naval do Gnome | Batalha naval
Servidor de batalha naval do Gnome | Servidor multijogador de batalha naval
Cliente de VideoLAN do Gnome | Reprodutor multimídia VideoLAN

###### Fornecendo a informação certa

Tente imaginar quais palavras os usuários estarão procurando quando selecionarem seu aplicativo do menu Aplicativos. Esta é a informação que deve estar no nome do menu. Por exemplo, um usuário que deseja reproduzir um filme provavelmente não estará procurando pela palavra "cliente". Por outro lado, um usuário que deseja transmitir filmes de seu computador poderá estar procurando pela palavra "servidor". Evite pensar no menu de aplicativos como uma ontologia!

##### Formatos do nome de menu

1. Caso o nome do seu aplicativo já seja descritivo de sua funcionalidade, e não apenas sugestivo, use o formato: Nome do aplicativo

   ###### Usando o nome do aplicativo como o nome de menu

   Nome do aplicativo | Nome de menu
   --- | ---
   Dicionário | Dicionário
   Ferramenta de pesquisa | Ferramenta de pesquisa

2. Caso haja uma descrição funcional sucinta de seu aplicativo, use o formato: NomeDoAplicativo DescriçãoFuncional

   ###### Usando descrições funcionais em nomes de menu

   Nome do aplicativo | Nome do item de meno
   --- | ---
   GIMP | Editor de imagens GIMP
   Sub-aplicativo de e-mail do Evolution | E-mail do Evolution
   AbiWord | Processador de texto AbiWord
   Galeon | Navegador web Galeon
   Gramps | Genealogia Gramps
   AisleRiot | Paciência AisleRiot

3. Alguns aplicativos, particularmente jogos, não possuem uma descrição funcional apropriada (mas note que vários jogos possuem). Neste caso, use Nome do aplicativo como o nome de menu.

   ###### Usando o nome do aplicativo como nome de menu onde nenhuma descrição funcional existe

   Nome do aplicativo | Nome do item de meno
   --- | ---
   Bomber Maze | Bomber Maze

#### Dicas de ferramenta do item de menu

As dicas de ferramenta fornecem aos usuários informações suficientes para executar o aplicativo correto. Muitos usuários usam as dicas de ferramenta para explorar um ambiente novo.

Forneça uma dica de ferramenta para cada item que você adicionar ao menu Aplicativos, seguindo estas diretrizes:

##### Diretrizes

- Expresse a dica de ferramenta por um verbo no imperativo, por exemplo "projete", "escreva" ou "cheque".

- Descreva as tarefas mais importantes que os usuários podem realizar com seu aplicativo.

- Embora dicas de ferramenta não devem ser prolixas, elas devem ser mais longas e descritivas que o nome do item.

##### Exemplos de dicas de ferramentas para aplicativos do GNOME

Aplicativo | Dica de ferramenta do item de menu
--- | ---
Mapa de caracteres | Insira caracteres especiais nos documentos
Memprof | Verifique seus aplicativos por vazamentos de memória
Same Gnome | Organize longas cadeias de bolas com cores similares para eliminá-las
Cliente de batalha naval do Gnome | Encontre e afunde navios inimigos nesta versão em rede de batalha naval

### Chaves do GConf

Chaves do GConf necessitam ter uma descrição longa e curta para cada chave. Muitas chaves não tem interface no aplicativo, então, para alguém administrando os valores das chaves a partir de outro aplicativo, cada campo de descrição será a única interface disponível.

#### Diretrizes

- Descrições curtas devem ser curtas, com menos que 8 palavras, descrevendo o propósito da chave

- Descrições longas devem ser completas ao descrever os possíveis valores da chave e os efeitos que esses valores terão no aplicativo

#### Exemplos de descrições para chaves do GConf do gnome-terminal

Chave | Descrição curta | Descrição longa
--- | --- | ---
background_type | Tipo de plano de fundo | Tipo de plano de fundo do terminal. Pode ser "sólido" para uma cor sólida, "imagem" para uma imagem, ou "transparente" para pseudo-transparência.
delete_binding | Efeito da tecla Delete | Determina qual código é gerado pela tecla delete. Valores possíveis são "ascii-del" para o caractere ASCII DEL, "control-h" para Control-H (também conhecido como o caractere ASCII BS), "escape-sequence" para a sequencia de escape tipicamente atado a backspace ou delete. "escape-sequence" é normalmente considerado a configuração correta para a tecla delete.

### Mapeando tipos de documento a aplicativos

O banco de dados de tipos do documento (MIME) permite que usuários especifiquem seu aplicativo preferencial para abrir diferentes tipos de documentos. Este é o mecanismo pelo qual Nautilus, Evolution e outros aplicativos decidem qual aplicativo executar quando encontram um documento que não podem abrir.

É importante que os usuários sejam capazes de abrir documentos que veem na área de trabalho com clique duplo, como arquivos e mensagens de email, e iniciar seu aplicativo favorito. Assim, seu aplicativo GNOME deve associar-se na hora da instalação com todos os tipos de documento que pode manusear. Detalhes técnico sobre como fazer isso podem ser encontrados na especificação das informações compartilhadas MIME e na especificação das entradas da área de trabalho do Freedesktop.

### Usando a área de notificação de estados

Ao usar a área de notificação de estados, os aplicativos podem notificar o usuário sobre eventos não críticos (por exemplo, a chegada de um novo email, ou um companheiro no chat que se conectou), e expõe o estado de processos ativos do sistema (por exemplo, imprimindo um documento, ou o carregamento da bateria do laptop).

Seguir as diretrizes nesta seção irá ajudar a esclarecer a diferença na mente do usuário entre a informação apresentada na área de notificação, e controles e informações apresentadas em outras partes do painel.

A utilidade da área de notificação diminui rapidamente quando mais que aproximadamente quatro ícones são apresentados constantemente. Por essa razão, ícones que aparecem apenas temporariamente em resposta à eventos são preferíveis.

#### Área de notificação ou miniaplicativo do painel?

Você provavelmente deve escrever um miniaplicativo ao invés de usar a área de notificação caso:

- clicar no ícone em sua área de notificação não faz nada além de abrir uma janela diretamente associada com o ícone (ex. uma janela de pasta de email para um ícone de novo email, ou a janela da fila de impressão para o ícone de notificação da impressora), ou

- há opções específicas do ícone no menu de contexto para fazer qualquer coisa além daquilo

- seu aplicativo alguma vez necessite exibir mais de um ícone de notificação ao mesmo tempo

#### Aparência do ícone

##### Diretrizes

- Use a perspectiva em tabela para ícones que representam dispositivos físicos, com a fonte de luz acima e a esquerda do objeto representado. Por exemplo, o ícone de impressora durante a impressão. Veja para mais informações sobre a perspectiva em tabela.

- Use a perspectiva de prateleira, com iluminação suspensa, para todos os outros ícones. Por exemplo, um envelope exibido quando um novo email chega. Veja para mais informações sobre perspectiva de prateleira.

- Para monitores ou barras de progresso que mudam ao longo do tempo, como o monitor da carga da bateria, delimite claramente a borda da área.

##### Diretrizes

- Somente os programas de núcleo do GNOME podem exibir perpetuamente um ícone na área de estados.

- Non-core programs for which a perpetual icon may be useful must default to not perpetually showing the icon. Users may select to enable a perpetual icon for the application as a preference.

#### Animação

##### Diretrizes

- Ícones normalmente não devem aparecer animados. Eles podem mudar para indicar uma mudança de estado, mas não deve fazer isso quando as mudanças ocorrem regular ou rapidamente. Um indicador do estado da bateria normalmente muda lentamente, portanto um ícone é apropriado. Em contraste, um medidor de carga sempre estaria carregando, portanto deve usar uma imagem plana.

- Qualquer ícone pode piscar para indicar um erro em deferência à mostrar um alerta. Por exemplo, um ícone de impressão em progresso pode piscar quando houver congestionamento de papel, mas não quando a impressora estiver pegando fogo - isso exibiria um alerta.

- Não dependa de animações ou de piscar como meio de alertar o usuário de algum evento em particular.

#### Interação

Ícones devem responder às alções dos usuários. (Pressionamentos de tecla se aplicam apenas quando o ícone tem foco, claro)

##### Diretrizes

- O duplo clique ou a tecla espaço devem realizar a ação padrão do ícone. Normalmente isso deve abrir uma janela com informações relevantes, por exemplo:

  - a fila de impressão para um ícone de impressão em progresso.

  - a caixa de entrada para um ícone de um email recebido

  - a mensagem para uma mensagem recebida

- O clique com o botão direito ou a combinação Shift F10 deve exibir um menu para o ícone contendo pelo menos a ação padrão do ícone.

- Caso as propriedades do ícone possam ser alteradas, deve haver um item de menu Propriedades no menu, e mostra seu painel de propriedades em resposta a Alt+Enter

- Ícones devem obedecer a convenções normais de dicas de ferramenta.

## Janelas

### Partes da janela e interação com o sistema

#### Títulos

Dê a cada janela um título (com exceção de alertas e caixas de ferramenta). Um bom título de janela contém a informação que é relevante ao usuário, e distingue uma janela particular de outras janelas abertas. Omita informação que não auxilia nesta seleção, por exemplo o número da versão do aplicativo ou o nome do vendedor.

##### Exemplo de um título de janela

Captura de tela mostrando uma barra de título de uma janela com título "Parts of Windows and System Interaction - Mozilla Firefox"

Veja a descrição de cada tipo particular de janela para formatos do título.

#### Comandos de bordas e janelas

A maioria das janelas possuem bordas, exceto algumas janelas perfiladas ou rasgadas. Não tente desenhar suas próprias bordas, em vez disso forneça dicas ao gerenciador de janelas para o tipo de borda desejada.

Comandos de janela diferentes são apropriados para diferentes tipos de janela. Veja a descrição de cada tipo particular de janela para uma lista dos comandos de janela apropriados. Esses são os comandos de janelas possíveis:

- ##### Fechar

  Fecha a janela. Sempre desenhe isso como um botão na borda da janela quando for relevante ao tipo de janela.

- ##### Maximizar

  Faz com que a janela use todo o espaço inutilizado da tela.

- ##### Minimizar

  Faz com que a janela seja temporariamente escondida. Continuará a aparecer na lista de janelas da área de trabalho.

- ##### Rolar/desenrolar

  Mostra apenas a barra de título da janela, como se tivesse sido "rolada"

#### Modalidade

Uma janela não modal não restringe a interação do usuário com outras janelas abertas na área de trabalho de maneira alguma. Usar janelas não modais dá ao usuário flexibilidade máxima para executar tarefas dentro de seu aplicativo em qualquer ordem e de quaisquer meios que escolher.

Uma janela modal de aplicativo, enquanto estiver aberta, previne o usuário de interagir com outras janelas no mesmo aplicativo.

Uma janela modal de sistema, enquanto estiver aberta, previne o usuário de interagir com qualquer outra janela em qualquer aplicativo, incluindo a própria área de trabalho.

##### Diretrizes

- Use uma janela modal de aplicativo somente se permitir a interação com outras partes do aplicativo enquanto a janela estiver aberta puder causar perda de dados ou outros problemas sérios. Forneça uma maneira óbvia de sair da janela modal, como um botão cancelar em um alerta.

- Não use janelas modais de sistema.

#### Foco

O foco é o meio pelo qual o usuário designa qual janela deve receber informações do teclado, mouse ou outro dispositivo de entrada. Caso esteja usando um leitor de tela ou alguma tecnologia assistiva similar, o foco pode também designar a janela que o usuário deseja receber informações. A janela focada é considerada a janela que o usuário está atualmente "trabalhando".

Certifique-se que seu aplicativo funciona corretamente com os três mecanismos diferentes pelos quais as janelas podem receber foco no GNOME:

- ##### Clicar para focar

  A janela é focada clicando nela.

- ##### Apontar para focar

  A janela é focada movendo o ponteiro do mouse sobre ela. Também conhecido como "foco desleixado".

- ##### Foco do teclado

  A janela é focada usando um atalho do teclado como Alt Tab.

##### Restrições especiais para apontar para focar.

Note que o apontar-para-focar coloca uma série de restrições em aplicativos GNOME que não estão presentes em ambientes como MacOS ou Windows. Por exemplo, janelas de utilidade compartilhadas entre janelas de múltiplos documentos, como a caixa de ferramentas do editor de imagens GIMP, não podem ser sensíveis ao contexto - isto é, não podem iniciar uma ação como Salvar no documento atual. Isto porque enquanto estiver movendo o ponteiro do documento atual para a janela de utilidade, o usuário pode inadvertidamente passar o ponteiro sobre uma janela diferente, mudando o foco e possivelmente salvando o documento errado.

#### Exibindo e ocultando janelas

Como seu aplicativo exibe e oculta janelas pode afetar muito a percepção do usuário de seu aplicativo, particularmente sobre sua performance.

##### Diretrizes

- Sempre exiba uma janela o mais rápido possível, mas tenha certeza de que sua janela tenha o tamanho correto antes de mostrá-la. Redimensionar uma janela depois de exibi-la é desorientador e dá um aspecto rude ao seu aplicativo.

- Caso uma janela tenha uma informação que demore alguns segundos para computar ou exibir, é geralmente melhor não carregá-la completamente antes de exibir a janela. Por exemplo, uma janela contendo uma grande área de texto pode ser exibida rapidamente, e então o texto pode ser preenchido posteriormente (desde que isso não resulte no redimensionamento da janela). Isso fará com que seu aplicativo pareça mais responsivo do que se você não tivesse exibido a janela até que seu conteúdo estivesse completo.

- Oculte uma janela o mais rápido possível depois que for fechada. A não ser que um alerta seja exibido, imediatamente oculte a janela na qual o usuário tenha fechado clicando no botão Fechar na borda da janela - seu aplicativo pode executar alguma operação de limpeza posterior. Além de fazer com que o sistema pareça lento, não fazer isso pode fazer com que o gerenciador de janelas pense que o aplicativo não está respondendo, e exiba um alerta desnecessário ao usuário.

### Janelas primárias

Uma janela primária geralmente apresenta uma visualização das informações do usuário, como um documento de texto em um processador de textos, uma imagem em um programa de desenhos, ou cálculos em uma calculadora ou uma planilha. Também pode ser uma visualização de algo mais abstrato, como um jogo. Uma única instância de um aplicativo pode ter mais de uma janela primária, e mais de um tipo de janela primária.

Uma janela primária é sempre exibida na lista de janelas do painel.

#### Uma janela primária típica (gedit)

Uma janela primária típica: uma visão de documento do gedit

Uma janela primária normalmente tem uma borda, uma barra de menu, uma barra de status, e também pode conter uma ou mais barras de ferramenta.

#### Título

O elemento mais importante do título da janela de um aplicativo baseado em documentos é o nome do documento aberto. Para outros aplicativos, é geralmente o nome do aplicativo.

##### Diretrizes

- Use o nome do arquivo como o título da janela para aplicativos baseados em documento. Não use o caminho completo, já que o nome do arquivo sozinho é mais fácil de distinguir entre outros títulos de janela, por exemplo na lista de janelas.

  ##### Usando nomes do documetos como título da janela

  Aplicativo | Exemplo de título de janela
  --- | ---
  AbiWord | Meu relatório.abw
  Evolution | Caixa de entrada
  Reprodutor de músicas | U2 - Better Than the Real Thing

  Caso o caminho do arquivo seja importante, por exemplo quando o usuário tem dois documentos com o mesmo nome abertos de diretórios diferentes no mesmo aplicativo, mostre o caminho completo na barra de status.

- Antes que um novo documento seja salvo pela primeira vez, defina o título da janela para <Tipo do documento> não salvo. Por exemplo, Desenho não salvo, Planilha não salva, ou genericamente Documento não salvo.

- Quando um documento tem mudanças pendentes, coloque um asterisco (*) no começo do título da janela. Por exemplo, *Desenho não salvo, *RelatórioAnual.

- Para aplicativos que não são baseados em documentos, use o nome do aplicativo como título da janela.

  ##### Usando nomes de aplicativos como título da janela

  Aplicativo | Título da janela
  --- | ---
  Dicionário | Dicionário
  Calculadora | Calculadora

- Não coloque números de versão, nomes de companhia, ou outra informação que não seja de uso imediato ao usuário no título da janela. Isto consome espaço, fazendo com que os títulos em espaços limitados como a lista de janelas do sistema menos úteis, e adiciona mais texto para o usuário ter que escanear para achar informação útil. Em um produto "beta", onde o número da versão é critico para informações de erros, colocar números de versão pode ser útil, mas remova-as das versões estáveis. Em vez disso, coloque a informação da versão no diálogo Sobre.

Enquanto nomes de documentos são mais adequados aos usuários, nós entendemos que desenvolvedores desejem aumentar o reconhecimento de seu aplicativo. Se você planeja incluir o nome do seu aplicativo no título da janela primária, use o seguinte formato: Nome do documento - Nome do aplicativo. Isso garante que o nome do documento apareça em situações de espaço limitado, como a lista de janelas do sistema.

Incluir o nome do aplicativo no título de um aplicativo baseado em documentos não é recomendado.

Pense sobre nomear janelas no contexto da lista de janelas do painel. Em uma tela típica com um número relativamente pequeno de janelas abertas, uma janela tem 20-30 caracteres de texto e um ícone. Considere qual texto pode dar as pistas mais imediatamente obvias para um usuário olhando para uma janela em particular.

#### Comandos de janela

Fechar, maximizar/restaurar, minimizar, enrolar/desenrolar

#### Relação entre documentos e janelas

##### Interface de documento único (IDU)

Uma interface de documento único coloca cada documento em sua janela primária. Caixas de ferramentas e outras janelas de utilidade podem ser compartilhadas entre múltiplos documentos IDU, mas fechá-los não deve ter efeito sobre as janelas de documento. Use IDU em seus aplicativos GNOME a não ser que tenha um motivo razoável para não fazê-lo.

###### Um típico aplicativo IDU (Visualizador de imagens)

Um típico aplicativo IDU: Visualizador de imagens sendo usado para inspecionar um ícone.

##### Interface de múltiplos documentos (IMD)

Uma interface de múltiplos documentos apresenta um visualizador em painéis, abas ou similar de dois documentos em uma única janela.

###### Um típico aplicativo IMD (gedit) exibindo três documentos abertos em páginas de abas.

Um típico aplicativo IMD: gedit com três documentos abertos na mesma janela.

IMD herda vários problemas de usabilidade, e por isso seu uso é desencorajado. É melhor abrir um documento em uma janela primária, com sua própria barra de menu, de ferramenta e de status, ou permitir múltiplas instâncias de seu aplicativo serem executadas simultaneamente. Em ambos os casos, isso deixa para o gerenciador de janelas (que age a partir das preferências do usuário) ao invés do seu aplicativo decidir como agrupar e apresentar janelas de documento do mesmo aplicativo.

##### Interface controlada de documento único (ICDU)

Em um típico aplicativo IDU, janelas de documentos são tratadas como primárias. Por exemplo, quanto todos os documentos tiverem sido fechados, o aplicativo (incluindo janelas de utilidade) também fecha. Em uma ICDU, uma janela de utilidades é tratada como a janela primária. Por exemplo, fechar a janela de utilidades irá fechar todos os documentos e sair do aplicativo.

Usar ICDU não é recomendado

Uma ICDU é ocasionalmente usada porque janelas de documento podem ser muito pequenas para possuírem barras de menu. Tipicamente esse não é o caso de uso normal para o aplicativo, mas representa um caso de uso significativamente minoritário. Por exemplo, um editor de imagens sendo usado para editar pequenos elementos de páginas da web resulta em várias pequenas janelas de documento que não podem acomodar uma barra de título.

Uma maneira melhor de resolver este problema é permitir que barras de menu "recolham" em um botão de estouro, do mesmo modo que barras de ferramentas operam quando a janela diminui para menos que a largura da barra de ferramentas. Isso permite pequenas janelas, mas também fornece uma oportunidade para que as pessoas descubram para onde seus menus foram.

Note que, caso documentos muito pequenos forem o caso de uso primário do seu aplicativo, considere encontrar um meio de evitar janelas completamente. Janelas não são interfaces efetivas para lidar com um número grande de pequenos itens. Considere buscar um sistema de layout fixo/automatizado para apresentar os "documentos". Também considere se os "documentos" vão ser usados primariamente em um agrupamento de nível mais alto, em cujo caso que o grupo se torna o documento.

### Janelas de utilidade

Janelas de utilidade, como paletas e caixas de ferramenta, normalmente tem bordas. Elas não contém uma barra de menu, de ferramenta ou de status.

Uma janela de utilidade não deve aparecer na lista de janelas do painel a não ser que, ou que possa ser, a única janela exibida pelo aplicativo. Caso contrário, a janela de utilidades deve ser elevada para frente do aplicativo quando a janela do aplicativo é selecionada a partir da lista de janelas.

#### Janelas de aplicação instantânea

Para janelas que permitem que o usuário mude valores e preferências, como janelas de preferências e propriedades, atualize esses valores ou configurações imediatamente para refletir as mudanças feitas na janela. Isso é conhecido como "aplicação instantânea". Não faça o usuário pressionar um botão OK ou Aplicar para fazer as mudanças acontecerem, a não ser caso:

- a mudança irá demorar mais que um segundo para ser aplicada, no caso em que aplicar as mudanças imediatamente pode fazer o sistema ficar lento ou não responsivo, ou

- as mudanças na janela devem ser aplicadas simultaneamente para prevenir o sistema de entrar em um estado potencialmente instável. Por exemplo, os campos nome de máquina e proxy em uma janela de propriedades.

Caso ambas as condições afetem apenas alguns poucos controles em sua janela, organize esses controles juntos em um ou mais grupos, cada um com seu próprio botão Aplicar. Deixe o resto dos controles como aplicação instantânea.

##### Diretrizes

- Não tente validar ou aplicar mudanças causadas por edição de um campo de texto até que o usuário tenha movido o foco para um controle diferente na janela, ou que a janela tenha sido fechada. Validar após cada pressionamento de tecla é geralmente irritante e desnecessário. Exceção: caso o campo aceite apenas um número fixo de caracteres, como um código de cor hexadecimal, valide e aplique a mudança tão logo o número de caracteres tenha sido digitado.

- Quando o usuário move o foco para um controle diferente, não indique uma entrada inválida exibindo um alerta ou desfazendo a mudança do usuário. Ambos os métodos são particularmente disruptivos para usuários em que o foco segue o mouse, para os quais o foco pode deixar o controle com maior frequência que acontece com os usuários em que o foco segue o clique.

#### Janelas de aplicação explícita

Caso a maioria dos controles em sua janela não são adequados para aplicação instantânea, considere fazer com que toda a janela seja de "aplicação explícita". Uma janela de aplicação explícita tem estes três botões em sua caixa de botões, e um botão opcional Ajuda:

- ##### Aplicar

  Aplica todas as configurações da janela, mas não fecha a janela caso o usuário queira mudar de ideia.

- ##### Cancelar

  Reinicia todas as configurações da janela para aquelas que estavam em vigor quando a janela estava aberta. Nota: isto deve desfazer os efeitos de todas as aplicações do botão Aplicar desde que a janela foi aberta, não apenas o mais recente.

- ##### OK

  Aplica todas as configurações da janela, e fecha a janela.

##### Botões em uma janela de aplicação explícita

Captura de tela mostrando o posicionamento correto dos botões Ajuda, Aplicar, Cancelar e OK em um diálogo

#### Botões padrão

Quando projetar um diálogo ou uma janela de utilidade, você pode atribuir a tecla Enter para ativar um botão particular na janela. O GNOME indica esse botão ao usuário desenhando uma borda diferente em torno dele. Por exemplo, o botão Ajuda em .

Escolha o botão padrão para ser a mais provável ação, como uma ação de confirmação ou uma ação que aplique as mudanças em uma janela de utilidade. Não faça um botão o padrão caso a ação seja irreversível, destrutiva ou inconveniente para o usuário. Caso não haja um botão apropriado em sua janela, para designá-lo como padrão, não estabeleça um.

Em particular, é atualmente não recomendado fazer o botão Fechar o padrão em uma janela de aplicação instantânea, já que isso pode fazer com que os usuários fechem a janela acidentalmente antes de terminar de usá-la.

#### Janelas de propriedade

Janelas de propriedade permitem que o usuário visualize e modifique as características de um objeto como um documento, arquivo, desenho ou lançador de aplicativo.

##### Exemplo de uma janela de propriedades

Captura de tela mostrando a janela "propriedades do arquivo" do Nautilus

##### Formato de título:

Propriedades do nome do objeto

##### Comandos de janela:

Fechar, minimizar, enrolar/desenrolar

##### Botões:

Coloque um botão Fechar no canto inferior direito. Um botão Ajuda pode ser colocado no canto inferior esquerdo.

#### Janelas de preferências

Janelas de preferências permitem que o usuário mude a maneira que um aplicativo se parece ou se comporta.

##### Exemplo de uma janela de preferências

Captura de tela mostrando a janela de preferências do Gnibbles

##### Formato de título:

Preferências do nome do aplicativo

##### Comandos de janela:

Fechar, minimizar, enrolar/desenrolar

##### Botões:

Coloque um botão Fechar no canto inferior direito. Um botão Ajuda pode ser colocado no canto inferior esquerdo.

##### Personalizando fontes e cores

Caso sua janela de preferências permita que o usuário personalize fontes e cores, use o seguinte estilo de redação e layout como guias para esses controles:

###### Estilo de redação recomendado para sobrescrever elementos do tema - substitua por captura de tela

    	(o) Usar fonte do tema
    	(o) Usar esta fonte: [Seletor de fonte]

    	(o) Usar cores do tema
    	(o) Usar estas cores:
    		Plano de fundo: [ seletor de cores ]
    		Primeiro plano: [ seletor de cores ]

O estilo de redação de botões de opção podem ser mais específicos onde for necessário, por exemplo, "Usar fonte monoespaçada do tema", ou "Usar cor de fundo do tema".

#### Caixas de ferramenta

Uma caixa de ferramenta fornece acesso conveniente à um conjunto de ações e alternâncias por meio de um conjunto de pequenos botões com estilo de barra de ferramentas. Caixas de ferramentas podem ser usadas para fornecer um grupo específico de ferramentas para acrescentar a uma barra de ferramentas que contém itens mais universais, como Salvar e Abrir. Uma única caixa de ferramentas pode ser compartilhada entre múltiplos documentos para economizar espaço na tela;

##### Exemplo de uma caixa de ferramentas

Uma captura de tela de uma caixa de ferramentas com oito botões organizados em duas linhas

##### Formato de título:

Caixas de ferramenta não têm título

##### Comandos de janela:

Fechar, enrolar/desenrolar

##### Botões:

Caixas de ferramenta não têm botões

##### Redimensionamento:

Faça com que as caixas de ferramenta sejam redimensionáveis, mas apenas redimensione discretamente pela largura dos itens da caixa de ferramentas. Em outras palavras, o usuário pode redimensionar a caixa de ferramentas para a largura de um item, dois itens, três itens, etc, mas não para um item e meio.

##### Diretrizes

- Coloque na caixa de ferramentas apenas botões que não abram outras janelas.

- Caixas de ferramentas são melhores usados para botões de alternância modais que afetam a operação do mouse no documento, como um conjunto de botões para escolher entre pincel, borracha e modos de preenchimento em um aplicativo de desenho. Botões que iniciam ações ao clique (como um botão de salvar) são melhor posicionados em barras de ferramentas.

- Assegure-se que fechar a caixa de ferramentas não fechará ou de outro modo alterará qualquer outra janela primária com a qual esteja associada.

- Não coloque caixas de ferramentas na lista de janelas do sistema. Caixas de ferramentas devem sempre ficar abaixo de todas as janelas primárias as quais estão associadas.

- Caso todas as janelas primárias associadas com a caixa de ferramentas estiverem fechadas ou minimizadas, esconda a caixa de ferramentas também. Exiba-a novamente quando uma das janelas primárias for aberta ou restaurada.

- Faça a caixa de ferramentas com dois itens de largura por padrão, a não ser que seja dividida em categorias. Faça caixas de ferramentas categorizadas com quatro itens de largura por padrão.

##### Categorias de caixa de ferramentas

Enquanto que categorias possam não ser tão visualmente atraentes quanto caixas de ferramentas homogêneas preenchidas com belos ícones, elas fazem com que uma caixa de ferramentas desajeitada e grande seja mais gerenciável. Escolher um ícone pequeno dentre quinze outros itens é uma tarefa difícil. Adicionalmente, categorias permitem que o usuário esconda conjuntos de itens que não são relevantes à sua tarefa atual.

###### Uma caixa de ferramentas larga dividida em categorias

###### Diretrizes

- Divida caixas de ferramentas com mais de dezesseis itens em categorias. O melhor tamanho para uma categoria é entre quatro e dez itens.

- Dê a cada categoria uma etiqueta (em capitalização de título) e uma seta de colapso. Clicar na etiqueta ou na seta alterna a categoria entre os estados colapsado e não colapsado.

### Alertas

Uma alerta fornece informações sobre o estado do sistema do aplicativo, ou pede por informações essenciais sobre como proceder com uma tarefa em particular. É distinto de outros tipos de janela já que não é requisitado diretamente pelo usuário, e geralmente contém uma mensagem ou questão ao invés de controles editáveis. Visto que alertas são uma intrusão indesejável no trabalho do usuário, não os use exceto onde necessário para evitar perdas de dados em potencial ou outros problemas sérios.

Um alerta tem bordas similares às de um diálogo, e é modal.

Um alerta não deve aparecer na lista de janelas do painel a não ser que seja, ou que possa ser, a única janela exibida pelo aplicativo. Por exemplo, um alerta lembrete de compromisso pode ser exibido após a janela principal do aplicativo de calendário ter sido fechada.

Caso contrário, um alerta deve ser destacado sobre o aplicativo quando a janela do aplicativo tiver sido selecionada da lista de janelas.

#### Exemplo de um alerta

Exemplo de um alerta exibindo o texto "You have an appointment with George Wells in 15 minutes", com um botão OK para dispersar a janela.

#### Formato do título

Janelas de alerta não tem títulos, já que o título duplicaria desnecessariamente o texto primário do alerta. Desta forma, usuários podem ler e responder a alertas mais rapidamente já que há menos ruído visual e texto confuso.

#### Redimensionar

Janelas de alerta não são redimensionáveis. Caso o usuário precise redimensionar seu alerta, o texto provavelmente não é conciso o suficiente.

#### Comandos de janela:

Nenhum

#### Alerta devem ficar sobre seus parentes.

Alertas não aparecem na lista de janelas do sistema. Consequentemente, assegure-se que alertas fiquem sobre suas janelas de origem. De outra forma, usuário certamente perderão o alerta e acharão seu aplicativo não responsivo por nenhuma razão aparente. Janelas modais devem sempre ficar na frente da(s) janela(s) que bloqueiam.

#### Textos de alerta

Um alerta pode conter tanto texto primário como secundário. O texto primário resume a situação. O texto secundário fornece informação adicional.

Faça com que tanto o texto primário quanto o secundário sejam selecionáveis. Isso facilita para o usuário copiar e colar o texto em outra janela, como uma mensagem de e-mail.

##### Localização do texto primário e secundário

Captura de tela de um alerta exibindo um exemplo de texto primário em negrito, e secundário em uma fonte menor abaixo.

##### Texto primário

O texto primário fornece ao usuário uma sentença que resume a informação ou ação sugerida. Esse resumo deve conter concisamente os detalhes essenciais do problema ou sugestão. Todo alerta tem um texto primário, exibido em negrito em fonte levemente maior que o padrão. O texto primário é pontuado no estilo 'manchete de jornal', isto é, não tem ponto final, mas pode conter um ponto de interrogação no final.

Indique o texto primário com a marcação pango:

    <span weight="bold"
          size="larger">Primary Text</span>

##### Texto secundário

Texto secundário fornece uma descrição mais profunda sobre o problema e a ação sugerida, incluindo possíveis efeitos colaterais. Texto secundário pode também fornecer informações que poderão ajudar o usuário a fazer uma decisão informada. Na maior parte das situações, o usuário deve necessitar apenas do texto primário para fazer uma decisão rápida, mas pode ler o texto secundário caso esteja inseguro do curso da ação, ou precise de detalhes extras. Texto secundário é opcional, mas quando utilizado, coloque uma linha de texto de altura abaixo do texto primário usando o tamanho e a largura padrão da fonte.

#### Botões de alerta

Dê a todos os alertas um botão afirmativo que dispensa o alerta e realiza a ação sugerida pelo botão primário. Forneça um botão Cancelar para todos os alertas exibidos em resposta às ações do usuário, como Sair. Caso o alerta avise o usuário de um problema técnico ou outra situação que poderia resultar em perda de informação, forneça um botão Ajuda que dê mais informações na situação em particular e explique as opções do usuário. Você também pode fornecer botões que executam ações alternadas que deem outra possível solução, corrija problemas em potencial, ou inicie programas ou diálogos relacionados.

##### Ordem e posição dos botões para alertas

Captura de tela mostrando a ordem e a posição dos botões do alerta: Ajuda na parte inferior esquerda e Alternar, Cancelar e Afirmativo na parte inferior direita.

##### Button Phrasing

Escreva as etiquetas de botões como verbos no imperativo, por exemplo Salvar ou Imprimir. Isso permite que o usuário selecione uma ação com menos hesitação. Uma frase ativa condiz também com o papel do botão em iniciar ações, em contraste com uma frase mais passiva. Por exemplo, Buscar e Conectar são botões melhores que Sim e OK.

- ##### Botões afirmativos

  Posicione os botões afirmativos no canto inferior direito do alerta. O botão afirmativo aceita a ação proposta pelo alerta, ou simplesmente dispensa o alerta caso nenhuma ação seja sugerida (como é o caso com alertas de informação).

- ##### Botão Cancelar

  Caso o alerta tenha sido produzido em resposta a uma ação do usuário, posicione um botão Cancelar imediatamente à esquerda do botão afirmativo. Isso fornece uma rota de fuga para que os usuários parem a ação em resposta à nova informação, ou caso simplesmente tenham clicado por acidente. Clicar no botão Cancelar reverte o aplicativo para seu estado anterior à ação do usuário.

- ##### Botão Ajuda

  Um botão Ajuda pode ser usado para esclarecer alertas que apresentam opções potencialmente destrutivas. Coloque o botão Ajuda no canto inferior esquerdo do alerta. Quando clicado, mostre uma janela de ajuda esclarecendo a situação, detalhando as ações executadas pelos outros botões, e explique qualquer efeito colateral que cada ação pode ter.

- ##### Botões alternados

  Botões extras podem ser usados para fornecer alternativas à ação primária proposta pelo texto do alerta. Posicione estes botões a esquerda do botão Cancelar, ou do botão afirmativo caso Cancelar não esteja presente. Um exemplo de uma ação alternativa comum seria o botão Sair sem salvar em um alerta de confirmação de salvamento. Esta é uma alternativa à ação sugerida Salvar e o botão Cancelar.

#### Espaçamento e posicionamento dentro dos alertas

Usar alertas limpos e com espaços consistentes fazem com que a mensagem seja mais fácil de digerir e as respostas a disposição, mais óbvias.

##### Espaçamento dentro de um alerta

Diagrama mostrando o espaçamento correto a ser usado entro controles e botõe em uma janela de alerta. Isto é detalhado nas diretrizes abaixo.

##### Diretrizes

- A borda ao redor de todos os cantos da aresta, bem como o espaço entre o ícone e o texto, é 12 pixels.

- O espaçamento horizontal entre botões é 6 pixels.

- Adicione uma quebra de linha com tamanho da fonte padrão abaixo de ambom os textos primário e secundário, ou 24 pixels caso esteja usando o Glade.

- Alinhe o topo do ícone com o topo do texto primário.

- Alinhe o texto da mensagem à esquerda, para localidades ocidentais.

##### Detalhes técnicos para um layout apropriado

Crie uma nova janela GtkDialog especificando o número de botões que deseja que o alerta contenha (e um botão de ajuda caso seja apropriado). O GtkDialog contém uma GtkVBox com a primeira linha vazia, e a última linha contendo um GtkButtonBox com botões. Na primeira linha vazia, coloque uma nova GtkHBox. Na coluna à esquerda da GtkHBox coloque uma GtkImage. À direita, coloque uma GtkLabel. Dentro da GtkLabel coloque o texto primáio primeiro (usando a marcação Pango apropriada, veja ), então coloque duas quebras de linha (retorno), e coloque o texto secundário. Agora mude as propriedades de cada controle de acordo com essas tabelas:

##### Propriedades para o GtkDialog

Propriedade | Valor
--- | ---
Título | (nenhum)
Largura da borda | 6
Tipo | Nível superior
Redimensionável | Não
Tem separador | Não

##### Propriedades para o GtkVBox (incluso no diálogo por padrão)

Propriedade | Valor
--- | ---
Espaçamento | 12

##### Propriedades para o GtkHBox

Propriedade | Valor
--- | ---
Espaçamento | 12
Largura da borda | 6

##### Propriedades para GtkImage

Propriedade | Valor
--- | ---
Alinhamento Y | 0.00
Tamanho do ícone | Diálogo

##### Propriedades para GtkLabel

Propriedade | Valor
--- | ---
Usar marcação | Sim
Quebrar texto | Sim
Alinhamento Y | 0.00

#### Alertas de informação

Use alertas de informação quando o usuário deve saber sobre a informação apresentada antes de continuar, ou tenha pedido a informação especificamente. Apresente informações menos importantes por outros meios, como a mensagem da barra de status.

##### Um alerta de informação

##### Um alerta de informação...

- usa o ícone de informação do estoque

- apresenta uma mensagem selecionável e um botão OK. O botão é posicionado no canto inferior direito do alerta. Pressionar Enter ou Escape esconde o alerta.

- pode apresentar um botão de conveniência para dar acesso à um objeto relevante. Por exemplo, um botão Detalhes em um lembrete de compromisso abre a janela de propriedades do compromisso. Posicione esse botão à esquerda do botão afirmativo.

##### Comandos de janela:

Enrolar/desenrolar, minimizar (caso o alerta não tenha janela pai), fechar

#### Alertas de erro

Mostre um alerta de erro quando uma operação solicitada pelo usuário não puder ser completada com sucesso. Apresente os erros causados por operações não solicitadas pelo usuário por outros meios, a menos que o erro possa resultar em perda de dados ou outros problemas sérios. Por exemplo, um erro encontrado durante uma verificação de email, iniciada pelo usuário ao clicar em um botão na barra de ferramentas, deve apresentar um alerta de erro. Entretanto, um erro encontrado em uma verificação automática e periódica de email seria reportado mais apropriadamente com uma mensagem na barra de status.

##### Um alerta de erro

##### Um alerta de erro...

- usa o ícone predefinido de erro.

- mostra uma mensagem selecionável e um botão OK. O botão é posicionado no canto inferior direito do alerta. Pressionar Enter pode dispensar o alerta de erro.

- pode apresentar um botão de conveniência para tratar imediatamente o erro. Por exemplo, um botão Formatar... em um alerta "Este disco não está formatado". Posicione este botão à esquerda do botão afirmativo.

##### Comandos de janela:

Rolar/desenrolar

#### Alertas de confirmação

Mostra um alerta de confirmação quando o comando do usuário pode destruir seus dados, criar um risco de segurança, ou pode levar mais de 30 segundos de esforço do usuário para de recuperar caso tenha selecionado erroneamente.

##### Um alerta de confirmação

##### Um alerta de confirmação...

- usa o ícone predefinido de alerta.

- mostra uma mensagem selecionável e um botão rotulado com um verbo ou uma frase verbal descrevendo a ação a ser confirmada, ou rotulado como OK caso a frase seja maior que 3 palavras. Este botão é posicionado no canto inferior direito do alerta.

- presents a Cancel button that will prevent execution of the user's command. This button is placed to the immediate left of the OK or equivalent button.

- may present an alternate action button or a convenience button. Place this button to the left of the Cancel button.

##### Comandos de janela:

Rolar/desenrolar

##### Save Confirmation Alerts

Save confirmation alerts help ensure that users do not lose document changes when they close applications. This makes closing applications a less dangerous operation.

###### A save confirmation alert

Save confirmation alert: "[ Close without Saving] [ Cancel ] [[ Save ]] "

###### Texto primário

Save changes to document Document Name before closing?

You may replace document with a more appropriate description, for example image or diagram if the document in question is not primarily text.

###### Texto secundário

If you close without saving, changes from the last Time Period will be discarded

The secondary text provides the user with some context about the number of changes that might be unsaved.

###### Buttons

Close without Saving, Cancel, Save

When a confirmation alert is needed, present it immediately. If the user confirms closing without saving, hide the alert and the document or application window immediately, before doing any necessary internal clean-up. If the user chooses to save before closing, hide the alert immediately but show the document window until the document is saved, in case an error occurs. Then hide the document window immediately after it has been saved successfuly.

#### Authentication Alerts

Authentication alerts prompt the user for information necessary to gain access to protected resources, such as their username or password. Authentication alerts are a special kind of alert because they are both routine and largely unavoidable. Every attempt should be made to retain information entered into an authentication alert as long as is possible within security constraints.

##### An authentication alert

##### Diretrizes

- Use the stock authentication icon.

- Show a labelled field for each required item of information. Suggested fields are Username and Password (in that order) where appropriate.

- If it is secure to retain the username longer than the password, pre-fill the username field and give focus to the password field when the alert is displayed.

- Show a button labelled with a verb or verb phrase describing the authentication action, or OK if there is no appropriate phrase or such a phrase would be longer than three words. Place this button in the bottom right corner of the alert.

- Do not enable the OK or equivalent button until all fields that require input have been attended to by the user. Remember that not all fields may require input however, for example an empty password may be acceptable in some applications.

- Show a Cancel button that will prevent authentication and close the alert. Place this button to the immediate left of the OK or equivalent button.

- Place any alternative action or convenience button to the left of the Cancel button.

- When the user presses Return in the last field, activate the default button. When the user presses Return in any other field, move focus to the next field.

##### Comandos de janela:

Rolar/desenrolar

### Progress Windows

A progress window can be used to provide feedback during an operation that takes more than a few seconds. See for more details about proper use of progress bars.

A progress window should always appear as an independent window in a window list. If progress of a task makes a window temporarily unusable, do not present a modal dialog-like progress window in front of it. Instead, present progress somewhere in the original window, making all its other elements temporarily insensitive. This helps reduce visual clutter.

#### An example of a progress window

An example of a progress window

#### Formato do título

Progress windows should have a title representing the overall operation: for example Copying Files, Installing, or Calling. As with other window titles, do not end progress window titles with an ellipsis.

#### Redimensionar

Progress windows should be resizable if they contain non-static information the user may want to copy (for example, the source URL in a download progress window). Otherwise they should not be resizable.

#### Diretrizes

- It is often better to use the progress bar contained in many primary windows' statusbar rather than a progress window. See for details on choosing between the two.

- Progress windows should use primary and secondary text like an alert. See

- The progress bar text should provide an idea of how much work has been completed. It is better to provide specific information rather than a unitless percentage. For example, "13 of 19 images rotated" or "12.1 of 30 MB downloaded" rather than "13% complete".

- If possible, an estimate of the time left until the operation is complete should also be included in the progress bar text. Indicate that the "time left" is an estimate using the word "about".

- Immediately beneath the progress bar, place italicized text indicating the current sub-operation being performed. This might be a step in a sequence, "Contacting control tower for permission to land", or it could be the current object being operated on in a bulk operation, "Rotating MonaLisa.png", "Rotating StarryNight.png".

- If the operation in progress is potentially hazardous (destructive, costly, etc) or heavily taxes a limited resource for more than ten seconds (network bandwidth, hard disk, CPU, etc), consider placing a Pause toggle button to the right of the Cancel button. When paused, the italicized current sub-operation text should have " (Paused)" appended. This will allow users to perform important tasks requiring that resource, or give them time to think whether they want to procede with a dangerous operation they inadvertantly triggered.

#### A progress window for a file copy operation

A progress window for a copy operation

#### Checklist Windows

Occasionally a procedure is comprised of a series of user performable actions. In these cases, particularly when it is desirable that the user acquire some familiarity with the actions involved in a procedure, checklist windows may be used.

##### Firewall Setup Wizard

A personal firewall setup wizard might install the firewall package, add entries for the firewall to /etc/xinetd.conf, restart the internet super-daemon, and configure the user's web browser to operate through the firewall. It may be desirable that the user is exposed to the series of actions involved in setting up the firewall to increase the chances that they will be sucessful in making modifications later, if they so desire.

##### An example checklist window (Ready to Start)

A checklist window

##### An example checklist window (In Progress)

A checklist window

##### An example checklist window (Completed)

A checklist window

##### Diretrizes

- If knowing the series of steps in an operation isn't that useful to the user, just use a regular progress window. Remember that you are probably more interested in the information than most users, many of whom will find the technical steps confusing rather than helpful.

- Unlike regular progress windows, checklist windows should not close automatically when the operation is complete and should require explicit user input before they begin. This is because one of their purposes is to inform the user concerning an operation's contingent steps.

- The progress bar indicates progress in the overall operation, not each step. While this is more difficult to program, it is the information most useful to the user. Just estimate how long each of the steps takes relative to each other and assign each step a fixed ratio of the progress bar's progress accordingly.

- Do not use a checklist window for a series of internal programmatic steps, use a regular progress window. For example "Connect to mail server", "Authenticate with mail server", "Download messages", "Disconnect" would not be an appropriate series of steps for a checklist window, but would be appropriate sub-operation steps for a regular progress window.

### Dialogs

A dialog provides an exchange of information, or dialog, between the user and the application. Use a dialog to obtain additional information from the user that is needed to carry out a particular command or task.

A dialog should not appear in the panel window list. Any open dialogs should be raised above the application when the application window itself is selected from the window list.

#### An example of a dialog

An example of a tabbed dialog: the GNOME print dialog

#### Formato de título:

Name of command that opened the dialog (without any trailing ellipsis)

#### Comandos de janela:

Minimize, Roll-up/Unroll

#### Botões:

Follow the guidelines for Alert buttons, see .

Your dialog may specify a default button, that is activated when the user presses the Return key. See for guidance on choosing an appropriate default button.

#### Additional Buttons

You can include other buttons in a dialog's main button area in addition to the affirmative button and Cancel, but any more than one or two such buttons will make the dialog appear complicated and difficult to use. As with any other button, keep the labels as concise as possible to minimize this effect.

##### Diretrizes

- Place buttons that apply to the dialog as a whole in the main button area row at the bottom of the dialog, to the left of the Cancel button.

- Place buttons that apply to one or a few controls next to their associated controls. For instance, place a Browse... button at the trailing edge of the text field it fills in.

#### Layout

A clean, logical dialog layout helps the user to quickly understand what information is required from them.

##### Diretrizes

- Arrange controls in your dialog in the direction that people read. In western locales, this is generally left-to-right, top-to-bottom. Position the main controls with which the user will interact as close to the upper left corner as possible. Follow similar guidelines for arranging controls within groups in the dialog, and for specifying the order in which controls are traversed using the Tab key.

- When opening a dialog, provide initial keyboard focus to the component that you expect users to operate first. This focus is especially important for users who must use a keyboard to navigate your application.

- Provide and show sensible default values for as many of the controls in your dialog as possible when it is opened, so the user does not have to generate the information from scratch. These defaults may come from system settings (for example, hostname or IP address), or from information that the user has previously entered in this or another application (for example, email address or network proxy).

See for more detailed information on arranging controls in dialogs.

See for information on using tabbed notebook controls in dialogs.

#### Common Dialogs

The gtk and GNOME libraries provide standard dialogs for many common tasks, including opening and saving files, choosing fonts and colors, and printing. Always use these when the user is performing one of these tasks. You may modify the dialogs to reflect the needs of your particular application (for example, adding preview Play and Stop buttons to the Open File dialog in an audio application), but do not change or remove features so much as to make them unrecognizable.

### Assistants

An assistant is a secondary window that guides the user through an operation by breaking it into sequential steps. Assistants are useful for making complex operations less intimidating, as they restrict the information visible to the user at any given moment.

Because assistants provide a relatively small number of controls on the screen at any given time, they have sufficient space for inline documentation. Therefore, do not include a Help button in an assistant window. If you cannot make an operation sufficiently clear in an assistant without resorting to a Help button, you need to simplify it further.

Assistants do have major downsides. After using an assistant it is often hard to figure out where the individual settings aggregated into the assistant are stored. Often people will resort to re-running the assistant, re-entering many settings that they don't want to change.

Assistants are often used in situations where a better solution would be to simplify, or even better automate, the process. Before using an assistant to step people through a complex operation, consider if the operation can be fundamentally simplified so an assistant is unnecessary.

#### Comandos de janela:

Close, Minimize/Unminimize, Roll-up/Unroll

#### Introductory Page

The first page provides the user with the "big picture". Place the title of the assistant in the window's title bar and the assistant's title area, along with an optional picture. Beneath this, state the goal of the assistant, and, if it is not obvious, where the user can find the information the assistant will be asking for.

##### Formato de título:

Assistant Title

##### Botões:

Cancel, Forward

##### Example of the first page of an assistant

Screenshot showing the first page of an assistant for creating a new email account

#### Content Pages

Content pages contain the actual settings of the assistant. Summarize the type of setting present on each content page in its title area. For example, Mail Server.

##### Formato de título:

Assistant Title - (Current Page of Total Pages)

##### Botões:

Cancel, Back, Forward

#### Last Page

The last page should summarize the settings that will be changed by the assistant, and how the user can modify them later.

##### Formato de título:

Finish Assistant Title

##### Botões:

Cancel, Back, Finish

## Menus

Menus present the whole range of an application's commands to the user, and often a subset of its preferences. When designing a new application, place common menu items in the same locations as they appear in other applications, as this makes it much easier for the user to learn.

In most applications, only primary windows should have a menubar. Utility windows and dialogs should be simple enough that their functions can be provided by controls such as buttons placed within the window.

Occasionally, however, a utility window or dialog is so complex that there would be too many such controls. In this case, you may use a menubar provided that:

- the menus follow the same standard layout as described in

- the window does not include a dialog button area or any buttons that dismiss it, such as OK, Close or Cancel. Place these commands on the File menu or equivalent instead.

### Diretrizes

- Label menu items with verbs for commands and adjectives for settings, according to the rules in .

- Make a menu item insensitive when its command is unavailable. For example, the Edit Copy item, which issues the command to copy selected data to the clipboard, should not be active when there is no data selected.

- Provide an access key for every menu item. You may use the same access key on different menus in your application, but avoid duplicating access keys on the same menu. Note that unlike other controls, once a menu is displayed, its access keys may be used by just typing the letter; it is not necessary to press the Alt key at the same time.

- Design your menu structure to avoid more than one level of submenus. Deep menu hierarchies are harder to memorize and physically difficult to navigate.

- Do not have menus with less than three items on them (except the standard Help menu, which has only two items by default). If you have a submenu with fewer than three items on it, move them into their parent menu. If you have a top-level menu with fewer than three items on it, find another suitable menu to add them to, or find suitable items from other menus to add to it.

### The Menubar

#### A typical menubar

A typical application menubar, showing File, Edit, View, Insert, Format, Go, Bookmarks, Tools, Windows and Help menus

The menubar provides a number of drop-down menus. Only the menu titles are displayed, until the user clicks on one of them.

The menubar is normally visible at all times and is always accessible from the keyboard, so make all the commands available in your application available on the menubar.

#### Full screen mode

When your application is running in full screen mode, hide the menubar by default. However, make its menus and items accessible from the keyboard as usual. Pressing ESC should cause the application to leave full screen mode. A Leave Fullscreen button should be placed in the upper right hand corner of the window. The button should disappear after the mouse is unused for 5 seconds, and should appear again when the moused is moved. Alternately, in applications where the mouse is used frequently in full screen mode, all but a two pixel row of the button may be slid off the top of the screen. The button should slide back on the screen when the mouse moves near it.

#### Diretrizes

- Provide a menubar in each primary application window, containing at least a File and a Help menu.

- Organize menu titles in the standard order— see

- Do not disable menu titles. Allow the user to explore the menu, even though there might be no available items on it at that time.

- Menu titles on a menubar are single words with their first letter capitalized. Do not use spaces in menu titles, as this makes them easily-mistaken for two separate menu titles. Do not use compound words (such as WindowOptions) or hyphens (such as Window-Options) to circumvent this guideline.

- Do not provide a mechanism for hiding the menubar, as this may be activated accidentally. Some users will not be able to figure out how to get the menu bar back in this case.

### Types of Menu

#### Drop-down Menus

##### A typical drop-down menu

Screenshot of a typical drop-down menu

A drop-down menu appears when the user clicks on its title in a menubar, or focuses the title and presses Return.

##### Diretrizes

- Only place items on a menu that relate to that menu's title.

- Organize menu items in the standard order— see . For application-specific items where there is no standard order, arrange in numerical or other logical order (for example, 50%, 100%, 200%), task order (for example, Compile followed by Debug) or by expected frequency of use.

- Limit top-level menus to a maximum of about 15 items. If you have any more items than this, consider moving a functionally-related subset of the items into a submenu or a new top-level menu.

- Do not add or remove individual menu items while the application is running, make them insensitive instead. Entire menus may be added or removed from the menubar at runtime, however, for example in component-based applications.

- Immediately update menu items that are edited directly or indirectly by the user, such as those on the Open Recent submenu and the Bookmarks menu.

#### Submenus

##### A drop-down menu with a submenu

Screenshot of a drop-down menu with a submenu

A submenu appears when the user clicks its title, which is indicated by a small arrow symbol beside its label. You can save space on long menus by grouping related commands onto a single submenu.

##### Diretrizes

- Use submenus sparingly, as they are physically difficult to navigate and make it harder to find and reach the items they contain.

- Do not create submenus with fewer than three items, unless the items are added dynamically (for example the File New Tab submenu in gnome-terminal).

- Do not nest submenus within submenus. More than two levels of hierarchy are difficult to memorize and navigate.

#### Popup Menus

##### A popup menu for a mail folder

Screenshot of a popup menu for a mail folder, listing the actions that can be performed on that folder

Popup menus provide shortcuts to those menu items that are applicable only to the currently selected object. As such, they are sometimes known as "context menus" or "shortcut menus". A popup menu is shown when the user right-clicks on an object, or selects the object and presses Shift F10.

Be aware that popup menus are used primarily by intermediate and advanced users. Even some users who have used graphical desktops for many years do not know about popup menus until somebody shows them.

##### Diretrizes

- Provide a popup menu for every object, selectable part, and text input target such as entry fields.

- Provide an access key for each item. However, to enhance their spatial efficiency and readability, do not show keyboard shortcuts in popup menus.

- Since the user may not be aware of their presence, do not provide functions that are only accessible from popup menus unless you are confident that your target users will know how to use popup menus.

- Order items on a popup menu as follows:

  - the double-click action for object, when it exists

  - other commands and settings in expected frequency-of-use order

  - transfer commands such as `Cut`, `Copy`, and `Paste`

  - Input Methods, where applicable. Input Methods is provided by GTK+ for supporting alternatives to the keyboard for input (such as used for Japanese, Chinese, and some accessibility technologies).

- Popup menus need to be as simple as possible to maximize their efficiency. Do not place more than about ten items on a popup menu, and do avoid submenus.

### Designing a Menu

#### Grouping Menu Items

##### Items grouped on a menu with separators

Screenshot of a menu divided into five logical groups with menu separators

Menu separators are the horizontal dividing lines that visually separate groups of related items on a drop-down menu, submenu, or popup menu. For example, the separators in divide the menu into five functionally-related groups. Good use of separators helps to "chunk" the information on a menu and make it easier to scan and memorize.

##### Diretrizes

- The best size for a group is around 2-5 items. Single-item groups are best placed at the top or bottom of a menu, otherwise try to group them with other single items of the same type on the same menu.

- Order items within a group logically, numerically, in task order or by expected frequency of use, as appropriate.

- Only place one type of menu item in each group— command, mutable, check box or radio button. For example, do not place commands (such as View Reload) and settings (such as. View Toolbar) in the same group.

#### Types of menu item

##### Command Items

###### A group of command items on a menu

Screenshot of a group on a menu containing only command items: Save, Save As, and Revert

Command items are menu items that initiate a command or perform an action, such as Save, Print or Quit. They may act on the currently active document in a document based application, or on the application itself.

###### Diretrizes

- Provide a keyboard shortcut for standard or frequently used command items. See for more information on choosing shortcut keys.

- Do not remove command items from the menu when they are unavailable, make them insensitive instead. This allows the user to infer what functionality the application provides even if it is not currently available, and keeping the menu structure static makes it easier to memorize.

- Label the menu item with a trailing ellipsis ("...") only if the command requires further input from the user before it can be performed. Do not add an ellipsis to items that only present a confirmation dialog (such as Delete), or that do not require further input (such as Properties, Preferences or About).

##### Mutable Command Items

A mutable command item changes its label when selected. For example, View Reload in a browser may change to Stop to allow the user to interrupt the operation if it is taking a long time.

Note that mutable menu items can be problematic because the user never sees the menu item changing, so it is not obvious that a different function has become available.

###### Diretrizes

- If your mutable menu items are command items, and you have sufficient space on your menu, consider providing two adjacent menu items for the commands instead. Then make the items sensitive or insensitive as the situation demands. This also makes it easier for the user to tell when different shortcuts are available for each of the commands, for example Ctrl R for Reload, and Esc for Stop.

- Do not use mutable menu items to toggle a two-state setting (for example, Show Toolbar and Hide Toolbar). Present such items as a single check box item instead.

##### Checkbox Items

###### A group of check box items on a menu

Screenshot of group on a View menu containing four check box items: Main Toolbar, Side Pane, Location Bar and Status Bar

A check box menu item shows the current state of a two-state setting, and allows the user to toggle it by selecting the menu item.

###### Diretrizes

- Use a check box menu item only when it is obvious from the label what the set and unset states mean. This usually means that the two states are logical or natural opposites, such as "on" and "off". If this is not the case, use two radio button items instead.

- Never change the label of a check box menu item in response to the user selecting the item.

##### Radio Button Items

###### A group of radiobutton items on a menu

Screenshot of group on a menu containing three radiobutton items: view as icons, view as list and view details

Radio button menu items show which of two or more mutually-exclusive settings are currently selected, and allow the user to choose a different setting by selecting its menu item.

- If you need to offer a choice of two mutually-exclusive settings to the user, use a group of two radio button items instead of a single check box menu item if the settings are not clearly opposites. For example, represent View as Icons and View as List as two radio button items.

- Never change the label of a radio button menu item in response to the user selecting or deselecting the item.

### Standard Menus

Most applications have many functions in common, such as Cut, Copy, Paste and Quit. To aid learning and memorability, these menu items, and the menus on which they appear, must appear with the same labels and in the same order in every application. The same commands must also behave the same way in different applications, to avoid surprising the user.

This section details the most common menus, menu items and their behaviors. You will not need all of these menus or menu items in every application you write, but do preserve the order of the menu titles and of the menu items that you do use.

#### Diretrizes

- Place application-specific menus after the Format menu and before the Go menu

- Place application-specific menu items towards the middle of a standard menu, unless they logically fit with one of the standard groups already on the menu.

#### A menubar showing all the standard menu titles in their correct order

- File
- Edit
- View
- Insert
- Format
- Go
- Bookmarks
- Windows
- Help

#### File

The File menu contains commands that operate on the current document. It is the left-most item in the menubar because of its importance and frequency of use, and because it is a relevant menu in many applications. Historically, because most applications already had this menu, and because the distinction between closing documents and closing windows became blurred over time, the File menu has also become the standard location for Quit.

The items on the File menu are generally ordered by locality, closest first. That is, items to save or load from file, followed by printing, followed by sending to a remote user. Try to maintain this ordering if you have to add new items to the menu.

If your application does not operate on documents, name this item for the type of object it displays. For example, many games should have a Game instead of a File menu. However, place the Quit menu item last on this menu nonetheless.

##### A generic File menu

    File
    New                  Ctrl+N
    Open...              Ctrl+O

    ---
    Save                 Ctrl+S
    Save As...     Shift+Ctrl+S
    Save a Copy...
    Revert
    ---
    Page Setup
    Print Preview  Shift+Ctrl+P
    Print...             Ctrl+P
    Send To...              Ctrl+M
    ---
    Properties
    ---
    1. Recent Document
    2. Recent Document
    3. Recent Document
    4. Recent Document
    ---
    Close               Ctrl+W
    Quit                 Ctrl+Q

##### Creation and Opening Operations

###### Creation and Opening operation menu items

Label | Shortcut | Description
--- | --- | ---

New

Ctrl N

Creates a new document. Open a new primary window, with the title Document name, containing a blank document. How this window is displayed, e.g. as a tab or a separate window, is up to the window manager.

If your application can create a number of different types of document, you can make the New item a submenu, containing a menu item for each type. Label these items New document type, make the first entry in the submenu the most commonly used document type, and give it the Ctrl N shortcut.

Note: A blank document will not necessarily be completely blank. For example, a document created from a template may already contain some data.

Open... | Ctrl O | Opens an existing document in a new window. Present the user with a standard Open File dialog from which they can choose an existing file. If the chosen file is already open in the application, raise that window instead of opening a new one.

##### Saved State Operations

###### Saved State Operation menu items

Label | Shortcut | Description
--- | --- | ---

Save

Ctrl S

Saves the document with its current filename. If the document already has a filename associated with it, save the document immediately without any further interaction from the user. If there are any additional options involved in saving a file (eg. DOS or UNIX-style line endings in a text file), prompt for these first time the document is saved, but subsequently use the same values each time until the user changes them.

If the document has no current filename or is read-only, selecting this item should be the same as selecting Save As.

Save As... | Shift Ctrl S | Saves the document with a new filename. Present the user with the standard Save As dialog, and save the file with the chosen file name.

Save a Copy...

Nenhum

Prompts the user to enter a filename, with which a copy of the document is then saved. Do not alter either the view or the filename of the original document. All subsequent changes are still made to the original document until the user specifies otherwise, for example by choosing the Save As command.

Like the Save As dialog, the Save a Copy dialog may present different ways to save the data. For example, an image may be saved in a native format or as a PNG.

Revert | Nenhum | Reverts the document to the last saved state. Present the user with a warning that all changes will be lost, and offer the option of cancelling before reloading the file.
Save Version... | Nenhum | An alternative to the Save a Copy command. Only use this item in conjunction with the Restore Version. command.
Restore Version... | Nenhum | Prompts the user for a version of the current document to be restored. Present the user with with a warning that all changes will be lost, and offer the option of cancelling before restoring the version. Only use this item in conjunction with the Save Version command.
Versions... | Nenhum | An alternative to the Save Version and Restore Version commands. Use this when more utilities, such as a diff, are available.

##### Export Operations

###### Export Operation menu items

Label | Shortcut | Description
--- | --- | ---
Page Setup | Nenhum | Allows the user to control print-related settings. Present the user with a dialog allowing the user to set such options as portrait or landscape format, margins, and so on.
Print Preview | Shift Ctrl P | Shows the user what the printed document will look like. Present a new window containing an accurate representation of the appearance of the document as it would be printed. The libgnomeprintui library provides a standard Print Preview window that you should use if possible.
Print... | Ctrl P | Prints the current document. Present the user with a dialog allowing them to set options like the page range to be printed, the printer to be used, and so on. The dialog must contain a button labelled Print that starts printing and closes the dialog. The `libgnomeprintui` library provides a standard Print dialog that you should use if possible.

Send To...

Ctrl M

Provides the user a means to attach or send the current document as an email or email attachment, depending on its format.

You may provide more than one Send item depending on which options are available. If there are more than two such items, move them into a submenu. For example, if only Send by Email and Send by Fax are available, leave them on the top-level menu If there is a third option, such as Send by FTP, place all the options in a Send submenu.

##### File Properties

###### Properties menu items

Label | Shortcut | Description
--- | --- | ---
Properties | Alt Return | Opens the document's Properties window. This may contain editable information, such as the document author's name, or read-only information, such as the number of words in the document, or a combination of both. The Alt Return shortcut should not be provided where Return is most frequently used to insert a new line.

##### Closing Operations

###### Closing Operation menu items

Label | Shortcut | Description
--- | --- | ---

Close

Ctrl W

Closes the current document. If it has unsaved changes, present the user with a confirmation alert giving the option to save changes, discard them, or cancel the action without closing or saving the document.

If the window you are closing is the last open document in the application, the correct action depends on your application type:

- Single document interface: close the application

- Controlled single document interface: leave only the control window open

- Multiple document interface: close the current document and create a new blank document

Quit

Ctrl Q

Closes the application. If there are unsaved changes in any open documents, present the user with a confirmation alert for each affected document, giving the option to save the changes, discard them, or cancel. If there are no unsaved changes, close the application immediately without presenting any further messages or dialogs.

In particular, non-document based applications, for example a game or a calculator, should save their state and exit immediately. This state should be restored the next time the application is started.

#### Edit

The Edit menu contains items relating to editing both the document (clipboard handling, search and replace, and inserting special objects) and the user's preferences. Preferences are edited here rather than on a Settings menu, because:

- most applications' preferences windows are accessed via a single menu item, and single-item menus offer poor usability

- most applications already contain a suitable Edit menu.

##### A generic Edit menu

    Edit
    Undo                 Ctrl+Z
    Redo           Shift+Ctrl+Z
    -
    Cut                  Ctrl+X
    Copy                 Ctrl+C
    Paste                Ctrl+V
    Paste Special...                Shift+Ctrl+V
    Delete               Del
    Select All           Ctrl+A
    Duplicate           Ctrl+U
    Deselect All   Shift+Ctrl+A
    -
    Find...              Ctrl+F
    Find Next            Ctrl+G
    Find Previous  Shift+Ctrl+G
    Replace...              Ctrl+R
    -
    Insert...
    -
    Preferences

##### Modification History

Document-based applications should maintain a history of modifications to a document and the state of the document between each action. The Undo and Redo commands move backwards and forwards through this history.

###### Modification History menu items

Label | Shortcut | Description
--- | --- | ---
Undo action | Ctrl Z | Undoes the effect of the previous action in the undo history list. Revert the document to its state before the previous action was performed. If your application supports undo, and the user undoes all changes since it was last saved, treat the document as unmodified. Note: provide a separate Undo and Redo menu item even if your application only supports one level of undo.
Redo action | Shift Ctrl Z | Performs the next action in the undo history list, after the user has moved backwards through the list with the Undo command. Move the user one step forwards again, restoring the document to the state it was in after that action was originally performed. Note: provide a separate Undo and Redo menu item even if your application only supports one level of undo.

##### Manipulating Selected Data

###### Selected Data Manipulation menu items

Label | Shortcut | Description
--- | --- | ---
Cut | Ctrl X | Removes the selected content and places it onto the clipboard. Visually, remove the content from the document in the same manner as Delete.
Copy | Ctrl C | Copies the selected content onto the clipboard.
Paste | Ctrl V | Inserts the contents of the clipboard into the document. If there is no current selection, use the caret as the insertion point. If there is a current selection, replace it with the clipboard contents.

Paste Special...

Shift Ctrl V

Inserts a non-default representation of the clipboard contents into the document. Open a dialog presenting a list of the available formats from which the user can select. For example, if the clipboard contains a PNG file copied from a file manager, the image may be embedded in the document, or a link to the file inserted so that changes to the image on disk are always reflected in the document.

Duplicate

Ctrl U

Creates a duplicate copy of the selected object. Do not prompt for a name for the duplicate object, but give it a sensible default (for example, `Copy of ShoppingList.abw`) and allow the user to change it later. Place the duplicate copy as near the original as possible without overlapping it, even if this means breaking the current sort order within the container, so the user sees it immediately.

Delete | Delete | Removes the selected content without placing it on the clipboard.
Select All | Ctrl A | Selects all content in the current document.

Deselect All

Shift Ctrl A

Deselects all content in the current document. Only provide this item in situations when no other method of undoing selection is possible or apparent to the user. For example, in complex graphics applications where selection and deselection is not usually possible simply by using the cursor keys.

Note: Do not provide Deselect All in text entry fields, as Shift Ctrl hex digit is used to enter unicode characters so its shortcut will not work.

##### Searching and Replacing

###### Search and Replace menu items

Label | Shortcut | Description
--- | --- | ---
Find... | Ctrl F | Opens a window or dialog allowing the user to search for specific content in the current document. Highlight each match in-place. If the command allows the user to search for content in places other than the current document, for example other open documents, other documents on disk, or a remote network location, label this item Search instead of Find.
Find Next | Ctrl G | Selects the next instance of the last Find term in the current document.
Find Previous | Shift Ctrl G | Selects the previous instance of the last Find term in the current document.
Replace... | Ctrl H | Opens a window or dialog allowing the user to search for specific content in the current document, and replace each occurrence with new content.

##### Inserting Special Objects

Where applicable, provide items on the Edit menu that insert special objects such as images, links, GUI controls or the current date and time.

If you have up to three types of object that can be inserted, add them as individual items to this menu, for example Insert Image, or Insert External Link. If you have between three and six types, place them on an Edit Insert submenu. If you have more than six, add a separate Insert menu to the menubar.

##### User Preferences

###### User Preferences menu items

Label | Shortcut | Description
--- | --- | ---
Preferences | Nenhum | Opens a preferences window allowing the user to change preferences for the whole application. Changes will apply to all running and subsequent instances of the application.

#### View

The View menu contains only items that affect the user's view of the current document. Do not place any items on the View menu that affect the content of the current document. (Exception: View Reload may change the current contents if, for example, the document is a webpage that has been recently updated on the server).

##### A generic View menu

    View
    Toolbar
    Statusbar
    ---
    Icons
    List
    Details
    ---
    Sort By...
    Filter...
    ---
    Zoom in       Ctrl++
    Zoom Out  Ctrl+-
    Normal Size   Ctrl+=
    Best Fit
    ---
    Refresh     Ctrl+R

##### Toolbar and Statusbar

###### Toolbar and Statusbar menu items

Label | Shortcut | Description
--- | --- | ---
Toolbar | Nenhum | Shows or hides the application's toolbar. This is a check box menu item. Include this item in every application that has a single toolbar. See for information on how to deal with multiple toolbars.

##### Content Presentation

###### Content Presentation menu items

Label | Shortcut | Description
--- | --- | ---
Icons | Nenhum | Shows the contents of the selected container as rows and columns of large icons, each with its name underneath. This is a radio button menu item.
List | Nenhum | Shows the contents of the selected container as a list of small icons, possibly in multiple columns, each with its name on its right-hand side. This is a radio button menu item.

Details

Nenhum

Shows the contents of the selected container as single column of small icons, each with its name on its right-hand side. Additional columns give extra information about the object each icon represents, for example the size and modification date of files in a file manager. This is a radio button menu item.

If your application has no need for both List and Details modes, use the List item for whichever of the two modes you support.

Sort By... | Nenhum | Sorts the contents of a container by user-specified criteria. Open a dialog allowing the user to choose from pre-defined sort keys (for example, Name, Size, or Modification Date in a file manager), or to specify their own if applicable.
Filter... | Nenhum | Hides objects that are not of interest to the user. Open a dialog allowing the user to choose from a list of types of object they want to display, or to enter their own criteria (for example, a regular expression matched against a particular property of the objects).
Zoom In | Ctrl+ | Zooms into the document. Make the center of the new view the same as the center of the previous view.
Zoom Out | Ctrl- | Zooms out of the document. Make the center of the new view the same as the center of the previous view.
Normal Size | Ctrl 0 | Resets the zoom level back to the default value, normally 100%. Make the center of the new view the same as the center of the previous view.
Best Fit | Nenhum | Makes the document fill the window. Show the document, or the current page of the document, at as high a zoom level as will fit in the window whilst allowing the whole document or page to be visible without scrolling.
Refresh | Ctrl R | Redraws the current view of the document from local storage. For example, in a web browser application, this would redraw the page from the browser page cache.
Reload | Ctrl R | Redraws the current view of the document, checking the data source for changes first. For example, checks the web server for updates to the page before redrawing it. If your application requires both Reload and Refresh, use Shift Ctrl R as the shortcut for Reload.

#### Insert

The Insert menu lists the type of special objects that can be inserted into the document at the current caret position, for example images, links, page breaks or GUI objects. Only provide this menu if you have more than about six types of object that can be inserted, otherwise place individual items for each type on the Edit menu.

##### A generic Insert menu

    Page Break
    Date and Time...
    Symbol...
    ---
    Sheet...
    Rows...
    Columns...
    ---
    Image...
    Graph...
    ---
    From File...
    External Link...

The types of object will vary between applications, but the table below shows some common types that may be applicable.

##### Insert menu items

Label | Shortcut | Description
--- | --- | ---
Page Break | Nenhum | Inserts a page break at the caret position. Show the page break visually, for example as a dotted line across the page, unless the user has specifically requested not to see them.
Date and Time... | Nenhum | Inserts the current date and/or time at the caret position. Open a dialog giving a choice of date and time formats. If applicable, also offer the choice to insert either as plain text, so the specified date and time will always appear in the document, or as a special field that will updated every time the document is opened, refreshed or printed.
Symbol... | Nenhum | Inserts a special symbol, such as a mathematical symbol or foreign character, at the caret position. Open a dialog showing all the available symbols as a table, from which the user can choose. The user must be able to add multiple symbols to the document at one time without having to close and re-open the dialog.
Sheet... | Nenhum | Adds a new sheet to the current workbook. Do not prompt for a name, but choose a sensible default (such as Sheet-2) and allow the user to change it later.
Rows... | Nenhum | Adds new rows to a table in which one or more rows or cells are currently selected. Open a dialog asking whether to insert rows above or below the current selection, and for any other required information. Copy the row format from the last or first row of the current selection respectively, unless the user specifies otherwise.
Columns... | Nenhum | Adds new columns to a table in which one or more columns or cells are currently selected. Open a dialog asking whether to insert columns to the left or right of the current selection, and for any other required information. Copy the column format from the right- or left-most column of the current selection respectively, unless the user specifies otherwise.
Image... | Nenhum | Inserts an image into the document from a file. Present a standard Open File dialog filtered on acceptable file types, from which the user can choose an image file to insert.
Graph... | Nenhum | Inserts a graph into the document. Open a dialog or assistant that allows the user to build (or open from a file) a graph of their choice, using the current selection as an indication of which values, axis labels and data labels to use.
From FIle... | Nenhum | Inserts an object from any acceptable file type, for example plain text, formatted text, or an image. Present a standard Open File dialog filtered on acceptable file types, from which the user can choose a file to insert.

External Link...

Nenhum

Inserts a link to an object stored in a different file, or on a remote system. The object is not embedded in or saved with the document, only a link to it. Open a dialog in which the user can type or choose the name of the object, for example a filename or a webpage URL. Show the link in the document in as informative way as possible. For example, show a link to an image as a thumbnail of that image, unless the user specifies otherwise.

#### Format

A Format menu contains commands to change the visual appearance of the document. For example, changing the font, color, or line spacing of a text selection.

The difference between these commands and those on the View menu is that changes made with Format commands are persistent and saved as part of the document, for example as HTML or RTF tags.

##### A generic Format menu

    Style...
    ---
    Font...
    Paragraph...
    ---
    Bold	Ctrl+B
    Italic	Ctrl+I
    Underline	Ctrl+U
    ---
    Cells...
    List...
    ---
    Layer...
    Page...

Items found on the Format will be very application-specific, but some common items are listed in the table below.

##### Format menu items

Label | Shortcut | Description
--- | --- | ---
Style... | Nenhum | Sets the style attributes of the selected text or objects either individually or to a named, predefined style. Open a dialog allowing the user to set attributes such as bold, italic, size and spacing individually, and to create their own named styles where applicable.
Font... | Nenhum | Sets the font properties of the selected text or objects. Open a dialog allowing the user to choose font, size, style, color, or whatever other attributes are applicable.
Paragraph... | Nenhum | Sets the properties of the selected paragraph. Open a dialog allowing the user to choose style, line spacing, tabulation, or whatever other attributes are applicable.
Bold | Ctrl B | Toggles the boldness of the current text selection on or off. If some of the selection is currently bold and some is not, this command should bolden the selected text.
Italic | Ctrl I | Toggles the italicisation of the current text selection on or off. If some of the selection is currently italicised and some is not, this command should italicise the selected text.
Underline | Ctrl U | Toggles underlining of the current text selection. If some of the selection is currently underlined and some is not, this command should underline the selected text.
Cells... | Nenhum | Sets the properties of the selected table cells. Open a dialog allowing the user to choose alignment, borders, shading, text style, number format, or whatever other attributes are applicable.
List... | Nenhum | Sets the properties of the selected list, or turns the selected paragraphs into a list if they are not already formatted as such. Open a dialog allowing the user to choose number or bullet style, spacing, tabulation, or whatever other attributes are applicable.
Layer... | Nenhum | Sets the properties of all or selected layers of a multi-layered document. Open a dialog allowing the user to choose name, size, visibility, opacity, z-ordering, or whatever other attributes are applicable.
Page... | Nenhum | Sets the properties of all or selected pages of the document. Open a dialog allowing the user to choose paper size, orientation, columns, margins, or whatever other attributes are applicable.

#### Bookmarks

Provide a Bookmarks menu in any application that allows the user to browse files and folders, help documents, web pages or any other large information space.

##### Icons

Show icons for bookmark entries on the Bookmarks menu that indicate the type of the bookmark, even if the user has globally turned off icons for other menu items on the desktop.

##### A generic Bookmarks menu

    Bookmarks
    Add Bookmark   CtrlD
    Edit Bookmarks CtrlB

##### Bookmark menu items

Label | Shortcut | Description
--- | --- | ---
Add Bookmark | Ctrl D | Adds a bookmark for the current document to the default bookmark list. Do not pop up a dialog asking for a title or location for the bookmark, instead choose sensible defaults (such as the document's title or filename as the bookmark name) and allow the user to change them later using the Edit Bookmarks feature.
Edit Bookmarks | Ctrl B | Allows the user to edit the application's bookmark list. Open a window in which the user can arrange bookmarks into a hierarchy, move, copy, and delete bookmarks, and change their properties.
Bookmark List | Nenhum | The user's current list of bookmarks for the application.

#### Go

A Go menu provides commands for quickly navigating around a document or collection of documents, or an information space such as a directory structure or the web.

The contents of the menu will vary depending on the type of application. Different standard menus are presented here for browser-based and document-based applications , but your application may require a combination of both.

##### A generic Go menu for a browser application

    Go
    Back       Alt+Left
    Forward	Alt+Right
    Up		Alt+Up
    ---
    Home	Alt+Home
    Location...  Ctrl+L

##### Go menu items for a browser application

Label | Shortcut | Description
--- | --- | ---
Back | Alt Left | Navigates to the previous document in the browser's history list.
Forward | Alt Right | Navigates to the next document in the browser's history list.
Up | Alt Up | Navigates to the current document's (or folder's) parent document (or folder). For a document browser, such as an online help viewer, this usually means navigating to the enclosing sub-section, section, chapter or contents page.
Home | Alt Home | Navigates to a starting page defined by the user or the application.
Location... | Ctrl L | Navigates to a user-specified URI. Open a dialog into which the user can type a suitable URI, or select one from a list where applicable (for example, a file selection dialog for applications that can handle file:// URIs).

##### A generic Go menu for document-based applications

    Go
    Previous Page 	PgUp
    Next Page      		PgDn
    Go to Page...
    -
    First Page    		Ctrl+Home
    Last Page		Ctrl+End

##### Go menu items for a document-based application

Label | Shortcut | Description
--- | --- | ---
Previous Page | PageUp | Navigates to the previous page in the document.
Next Page | PageDown | Navigates to the next page in the document.
Go to Page... | Nenhum | Navigates to a user-specified page number. Open a dialog into which the user can type a page number. Text-based applications may also include a Go to Line... menu item, which allows the user to jump to a specified line number.
First Page | Ctrl Home | Navigates to the first page in the document.
Last Page | Ctrl End | Navigates to the last page in the document.

#### Janelas

The Windows menu contains commands that apply to all of the application's open windows. Only use a Windows menu in multiple document interface (MDI) applications.

##### MDI Applications

The use of MDI is discouraged, as they have a number of inherent usability problems.

You may also label this menu Documents, Buffers, or similar according to the type of document handled by your application.

The last items on this menu are a numbered list of the application's primary windows, for example 1shoppinglist.abw. Selecting one of these items raises the corresponding window.

##### A generic Windows menu

    Windows
    Save All
    Close All

##### Windows menu items

Label | Shortcut | Description
--- | --- | ---
Save All | Nenhum | Saves all open documents. If any documents have no current filename, prompt for a filename for each one in turn using the standard Save dialog.
Close All | Nenhum | Closes all open documents. If there are any unsaved changes in any documents, post a confirmation alert for each one in turn.
1. first open window title 2. second open window title etc. | Nenhum | Raises the corresponding window to the top of the window stack.

#### Help

The Help menu provides access to all online documentation for your application. This includes both the user guide, and the About window which includes a brief description of your application's functionality.

##### A generic Help menu

    Help

    Contents      F1
    About

##### Help menu items

Label | Shortcut | Description
--- | --- | ---
Contents | F1 | Opens the default help browser on the contents page for the application.
About | Nenhum | Opens the About dialog for the application. Use the standard dialog provided by the GNOME libraries, which contains the name and version number of the application, a short description of the application's functionality, author contact details, copyright message and a pointer to the licence under which the application is made available.

## Toolbars

A toolbar is a strip of controls that allows convenient access to commonly-used functions. Most toolbars only contain graphical buttons, but in more complex applications, other types of controls such as drop-down lists, can also be useful.

### Example toolbar from a simple mail application

Example mail application toolbar

Careful and consistent toolbar design speeds up the user's task by giving direct access to functions that would otherwise be hidden on a menu. Use them only for the most important functions, however. Having too many toolbar controls reduces their efficiency by making them harder to find, and too many rows of toolbars reduces the amount of screen space available to the rest of the application.

### Appearance and Content

The effectiveness of toolbars is increased by maintaining a level of consistency between different applications. The toolbar is one of the first parts of your application that a user will see the first time they run it, so by providing a toolbar that looks familiar to them, you can immediately make them feel comfortable about using your application.

As well as following the recommendations and examples given in this section, look at the toolbars in other well-designed GNOME 2.0 applications for guidance when deciding what— and what not— to put on your application's toolbar.

However many toolbars or toolbox windows your application offers, provide one main toolbar by default that contains a representative subset of the application's overall functionality. Many of the buttons on this toolbar will be the same regardless of the type of application.

For example, the main toolbar in an office application will nearly always have New, Open and Save as its first three toolbar buttons. Similarly, the first few buttons in a browser application should always include Back, Forward, Stop and Reload, in that order.

#### Diretrizes

- Place only the most commonly-used application functions on your toolbars. Don't just add buttons for every menu item.

- By default, have your toolbars appear directly below the main menu bar.

- Allow toolbars to be turned on and off in your application's Preferences dialog and by using the View Toolbar menu item. If there is more than one toolbar, they are turned on and off by individual entries in the View Toolbar submenu.

- All functions that appear on your toolbars must also accessible via the main menu bar, either directly (i.e. an equivalent menu item) or indirectly (e.g. in the Options Settings dialog).

- Arrange toolbar buttons in the same order and groupings as their equivalents on the main menu bar. In particular, always group sets of mutually-exclusive toolbar buttons.

- Don't add buttons for Help, Close or Quit to your toolbar by default, as these are rarely used and the space is better used for more useful controls. Similarly, only provide buttons for Undo, Redo and the standard clipboard functions if there is space on the toolbar to do so without sacrificing more useful, application-specific controls.

- Provide options to show toolbar buttons as text, graphics or both— see for the menus to use for controlling toolbar display. Also provide an option to return all toolbars in your application to the control center default for this setting.

- Allow users to configure toolbars to contain their own selection of commands, in whatever order they choose. Provide an option in the configuration dialog to return the toolbars to their default configuration.

- Save your application's toolbar position and contents as part of the application configuration, and restore them when the application is restarted.

#### Vertical Toolbars

In general, don't use vertical toolbars. The eye does not scan vertically as well as it does horizontally, groups of mutually exclusive buttons are less obvious when arranged vertically, and showing button labels is more awkward and less space-efficient. Also, some toolbar controls just cannot be used vertically, such as drop-down lists.

Only consider using a vertical toolbar if:

- the configuration of the application window means there would be a lot of wasted space if a horizontal toolbar was used instead, or

- your application would otherwise require three or more rows of toolbars to appear below the main menu bar by default. Note however that in this situation, the better alternative is usually to display fewer toolbars by default.

If you must use a vertical toolbar, ensure the user can configure it to appear horizontally if they prefer.

#### Media Player Toolbars

Many applications are able to play sound or video clips. For consistency, always present the buttons that control playback in the same order and with the same stock icons.

##### Diretrizes

- Show separate Stop and Pause buttons. Do not change Play to Pause while the clip is playing.

### Controlling Display and Appearance

For each toolbar in your application, the user should be able to choose whether or not to show that toolbar, and whether to show its contents as icons only, text only or both.

#### Diretrizes

- Allow the user to override the control center toolbar defaults for your particular application in the application's Preferences dialog. In particular, ensure that the user can:

  - separately choose to show each toolbar in your application as icons only, text only, or both

  - return the icon/text/both status for all toolbars in your application to the system default

  - choose to show text labels either to the side of some or below all toolbar icons, and to return this setting to the system default

  - return the layout and ordering of all toolbars in your application to the application default

- If your application has a single toolbar, allow the user to turn it on or off with a View Toolbar check box menu item.

- If your application has two or three toolbars, allow the user to turn them on or off individually by placing a menu item for each one on the application's View menu. For example, Main Toolbar, Drawing Toolbar, Formatting Toolbar. Place the items together in a single group on the menu, with Main Toolbar first (if your application has one), followed by the others in alphabetical order.

- If your application has more than three toolbars, allow the user to turn them on or off individually by placing a menu item for each one in a Toolbars sub-menu on the application's View menu. Place the Main Toolbar item first (if your application has one), followed by the others in alphabetical order.

  #### Example View menu fragments for applications with one toolbar (left), two or three toolbars (middle), or four or more toolbars (right)

  Example View menu for application with single toolbar

### Labels and Tooltips

Most controls that appear on your toolbar will require a text label that appears on, below or beside it. Keep this description as short as possible, preferably a single verb. For example, Open or Undo.

Every control that appears on your toolbar should have a tooltip, whether or not that control has an associated text label. The tooltip should be a concise description of the control, but should provide more information than its text label where possible. For example, Open an existing document, or Undo last operation.

#### Diretrizes

- For buttons that correspond directly to menu items, make the text label the same as the menu item, but without any trailing ellipsis. For example, Open, Save.

- Do not provide access keys for toolbar buttons. Since toolbars are in the same keyboard focus context as the menubar, it would be too difficult to provide unique access keys for every menu title and toolbar control. Toolbars are primarily intended as a shortcut for mouse users, although they are keyboard-navigable for accessibility reasons.

- If your toolbar is configured to show labels below button icons, show a label for every control on the toolbar. For example:

  #### Toolbar with labels under all buttons

  Toolbar showing labels under all controls

- If your toolbar is configured to show labels beside button icons rather than below them (using the "priority text" setting), do not show labels for every button. Show labels only for the buttons that will be most-frequently used. Choose no more than four such icons on any one toolbar, otherwise the effect will be diluted and the toolbar will become very wide. For example:

  #### Toolbar with "priority text" labels beside the first few buttons only

  Toolbar with "priority text" labels beside the first few items only

  If you are unsure which buttons will be most frequently used, choose the first few buttons on your toolbar and provide labels for those only.

- Ensure all toolbar controls have tooltips. The tooltip should be more descriptive than the corresponding menu item, if it has one, but still concise. For example, Create new document for the Open toolbar button. Use sentence capitalization for tooltips—see for more information.

## Controls

### Using Controls Effectively

GNOME provides a set of controls, also known as widgets, which allow users to interact with your applications. Using these controls appropriately and not altering their standard behavior is important. This allows users to predict the effects of their actions, and thus learn to use your application more quickly and efficiently. Controls that behave in non-standard ways break the user's mental model of how your application works, and dilute the meaning of the interface's visual language.

### Terminology

Although they are known as "widgets" in the GNOME APIs and developer documentation, do not use this term in your user interface or user documentation. Refer to them by their specific names (for example, "buttons" or "menus"), or by the generic name "controls".

### Sensitivity

Sometimes it does not make sense to allow the user to interact with a control in the current context, for example, to press a Paste button when the clipboard is empty. At these times, make the control insensitive to minimize the risk of user error. While a control is insensitive, it will appear dimmed and will not be able to receive the focus, although assistive technologies like screenreaders will still be able to detect and report it.

It is usually better to make a control insensitive than to hide it altogether. This way, the user can learn about functionality they may be able to use later, even if it is not available right now.

#### Two check boxes: sensitive (top) and insensitive (bottom)

Screenshot showing the visual appearance of sensitive and insensitive check box controls

#### Locked Controls

In a network-managed environment, like a computer lab, system administrators usually want to "lock down" the values of certain settings, or remove them from the user interface altogether. This makes it easier for them to troubleshoot any problems that their users may encounter. In GNOME, the correct way for the system administrator to do this is by restricting write access to the GConf keys corresponding to those settings.

When you are designing your application, consider which settings a system administrator might want to make unavailable to users. These may typically include:

- Settings that, if set wrongly, could prevent the application from functioning at all. For example, proxy settings in a network application.

- Settings that could refer to networked resources. For example, the Templates directory in an office application, where shared stationery such as fax cover sheets might be stored.

- Settings that customize the user interface, other than those required for accessibility. For example, certain menu, keyboard or toolbar customization options.

Your application needs to decide every time these controls are displayed whether or not they are available for editing, depending on the writeable state of the GConf key that holds its value. In the simplest case, your code for each control could look like that in the example below.

##### Sample code fragment showing how to make a GConf-locked control insensitive

    if (!gconf_key_is_writable (http_proxy))
            gtk_widget_set_sensitive (http_proxy_field, FALSE);

Include a section for system administrators in your user guide, explaining which settings they can lock, and their corresponding GConf keys.

Explain to the user why these controls cannot be edited at this time. You can do this with static text, tooltips or online help, depending on the situation. For example:

##### Example of a dialog with locked controls

Screenshot showing disabled proxy controls in a web browser's property dialog, under the caption "Only the system administrator can change these settings"

Note that although they cannot be edited, the settings are still visible and selectable, and may be copied to the clipboard.

### Text Entry Fields

Text entry fields are used for entering one or more lines of plain text. In GTK 2, the GtkEntry control is used for single-line text entry, and GtkTextView for multiple-line text entry.

#### Single and multi-line entry fields

Screenshot of part of a dialog, containing both single and multi-line entry fields

#### Diretrizes

- Label the entry field with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the entry field.

- Right-justify the contents of entry fields that are used only for numeric entry, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned.

- When the user gives focus to an entry field using the keyboard, place the text cursor at the end of the existing text and highlight its contents (but don't overwrite the existing PRIMARY clipboard selection). This makes it easy to immediately overtype or append new text, the two most common operations performed on entry fields.

- Size text entry fields according to the likely size of the input. This gives a useful visual cue to the amount of input expected, and breaks up the dialog making it easier to scan. Don't make all the fields in the dialog the same width just to make everything line up nicely.

- In an instant-apply property or preference window, validate the contents of the entry field when it loses focus or when the window is closed, not after each keypress. Exception: if the field accepts only a fixed number of characters, such as a hexadecimal color code, validate and apply the change as soon as that number of characters have been entered.

- Provide a static text prompt for text boxes that require input in a particular format or in a particular unit of measurement. For example:

  #### Text entry field with static text prompt

  A text entry field in which the user must input a time, with the label "hh:mm" beside it to indicate the required format

- Where possible, provide an additional or alternative control that limits the required input to the valid range. For example, provide a spinbox or slider if the required input is one of a fixed range of integers, or provide access to a GtkCalendar control if the user has to enter a valid date:

  #### Text entry field requiring a date as input, with a button beside it to pop up a GtkCalendar control to simplify the task

  A text entry field in which the user must input a date, with a button labelled "Choose" beside it that opens a GtkCalendar control to simplify the task

  This is less error-prone than expecting the user to format their text input in some arbitrary format. You may still want to provide the entry field control as well, however, for expert users who are familiar with the required format.

- If you implement an entry field that accepts only keystrokes valid in the task context, such as digits, play the system warning beep when the user tries to type an invalid character. If the user types three invalid characters in a row, display an alert that explains the valid inputs for that textfield.

- The cursor blink rate is globally defined by the XSettings "gtk-cursor-blink" and "gtk-cursor-blink-time". Standard toolkit controls use these and they must not be altered in applications by any means. New controls with text cursors must respect these global values.

#### Behavior of Return key

Normally, pressing Return in a dialog should activate the dialog's default button, unless the focused control uses Return for its own purposes. You should therefore set the `activates-default` property of most entry fields to TRUE. (Note that GtkTextView does not have such a setting— pressing Return always inserts a new line.).

However, if your dialog contains several entry fields that are usually filled out in order, for example Name, Address and Telephone Number, consider setting the `activates-default` property on those entry fields to FALSE. Pressing Return should then move focus on to the next control instead. Doing this will help prevent the user from accidentally closing the window before they have entered all the information they wanted to.

As a further safeguard, remember not to set the default button in a dialog until the minimum amount of required information has been entered, for example, both a username and a password in a login dialog. Again, in this case you should move focus to the next control when the user presses Return, rather than just ignoring the keypress.

If you need to provide a keyboard shortcut that activates the default button while a GtkTextView control has focus, use Ctrl Return.

##### Note

Gtk does not currently move focus to the next control when Return is pressed and either `activates-default=FALSE`, or there is no default button in the window. For now, Return does nothing in these situations, so remember to implement the focus change behavior yourself.

#### Behavior of Tab key

Normally, pressing Tab in a single-line entry field should move focus to the next control, and in a multi-line entry field it should insert a tab character. Pressing Ctrl Tab in a multi-line entry field should move focus to the next control.

If you need to provide a keyboard shortcut that inserts a tab character into a single line entry field, use Ctrl Tab. You are unlikely to find many situations where this is useful, however.

### Spin Boxes

A spin box is a text box that accepts a range of values. It incorporates two arrow buttons that allow the user to increase or decrease the current value by a fixed amount.

#### Example of a spin box

A simple spin box used to specify the spacing between applets on a panel

#### Diretrizes

- Use spin boxes for numerical input only. Use a list or option menu when you need the user to select from fixed data sets of other types.

- Use a spin box if the numerical value is meaningful or useful for the user to know, and the valid input range is unlimited or fixed at one end only. For example, a control for specifying the number of iterations of some action, or a timeout value. If the range is fixed at both ends, or the numerical values are arbitrary (for example, a volume control), use a slider control instead.

- Label the spin box with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the spin box.

- Right-justify the contents of spin boxes, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned.

### Sliders

A slider allows the user to quickly select a value from a fixed, ordered range, or to increase or decrease the current value. The control looks like the type of slider that you might find on an audio mixing desk or a hi-fi's graphic equalizer. In gtk, you implement a slider using the GtkHScale or GtkVScale controls, for horizontal or vertical sliders respectively.

#### A simple slider control

A slider control used to change the stereo audio balance between left and right speakers

#### Diretrizes

- Use a slider when:

  - adjusting the value relative to its current value is more important than choosing an absolute value. For example, a volume control: the average user will usually think about turning the volume up or down to make a sound louder or quieter, rather than setting the peak output to a specific decibel value.

  - it is useful for the user to control the rate of change of the value in real time. For example, to monitor the effects of a color change in a live preview window as they drag the RGB sliders.

- Label the slider with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the slider.

- Mark significant values along the length of the slider with text or tick marks. For example the left, right and center points on an audio balance control in .

- For large ranges of integers (more than about 20), and for ranges of floating point numbers, consider providing a text box or spin box that is linked to the slider's value. This allows the user to quickly set or fine-tune the setting more easily than they could with the slider control alone.

  #### Slider controls with linked spin boxes

  Three slider controls used to change RGB values, each with a spinbox beside them to facilitate direct numeric entry

### Buttons

A button initiates an action when the user clicks it.

#### Typical buttons in a modal dialog

OK and Cancel buttons as found in a modal dialog

#### Diretrizes

- Label all buttons with imperative verbs, using header capitalization. For example, Save, Sort or Update Now. Provide an access key in the label that allows the user to directly activate the button from the keyboard.

- After pressing a button, the user should expect to see the result of their action within 1 second. For example, closing the window or opening another. See for guidance on what to do if your application cannot respond this quickly.

- Use an ellipsis (...) at the end of the label if the action requires further input from the user before it can be carried out. For example, Save As... or Find.... Do not add an ellipsis to commands like Properties, Preferences, or Settings, as these open windows that do not require further input.

- Once a dialog is displayed, do not change its default button from one button to another. You may add or remove default status from the same button if it helps prevent user error, however. Changing the default from one button to another can be confusing and inefficient, especially for users relying on assistive technologies.

- If your button can display text, an icon, or both, choose which label to display at runtime according to the user's preference in the GNOME Menus and Toolbars Preferences dialog. However, you may over-ride this preference when there is no suitable icon to describe the button's action graphically, for example.

- Do not use more than one or two different widths of button in the same window, and make all of them the same height. This will help give a pleasing uniform visual appearance to your window that makes it easier to use.

- Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover these actions, and if they do, it will distort their expectations of other buttons on the desktop.

- Make invalid buttons insensitive, rather than popping up an error message when the user clicks them.

In a dialog, one button may be made the default button, which is shown with a different border and is activated by pressing Return. Often this will be the OK or equivalent button. However, if pressing this button by mistake could cause a loss of data, do not set a default button for the window. Do not make Cancel the default button instead. See for more information.

If it does not make sense to have a default button until several fields in the dialog have been correctly completed—for example, both the Username and Password fields in a login dialog—do not set the default button until they have both been completed.

### Check Boxes

Check boxes are used to show or change a setting. Its two states, set and unset, are shown by the presence or absence of a checkmark in the labelled box.

#### A typical group of check boxes

A typical group of five check boxes in a dialog

#### Diretrizes

- Do not initiate an action when the user clicks a check box. However, if used in an instant-apply property or preference window, update the setting represented by the check box immediately.

- Clicking a check box should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.

- If toggling a check box affects the sensitivity of other controls, place the check box immediately above or to the left of the controls that it affects. This helps to indicate that the controls are dependent on the state of the check box.

- Use sentence capitalization for check box labels, for example Use custom font.

- Label check boxes to clearly indicate the effects of both their checked and unchecked states, for example, Show icons in menus. Where this proves difficult, consider using two radio buttons instead so both states can be given labels. For example:

  #### Ambiguous check box (top), radio buttons work better in this case (bottom)

  Two images: one showing a single check box ambiguously labelled "Progress bar in left of statusbar", the other making the choice explicit with radio buttons labelled "Left" and "Right" under the heading "Status bar progress indicator position:"

  The single check box in this example is ambiguous, as it is not clear where the "progress indicator" will go if the box is unchecked. Two radio buttons are better in this case, as they make the options clear.

- Provide an access key in all check box labels that allows the user to set or unset the check box directly from the keyboard.

- If the check box represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the check box in its mixed state. For example:

  #### Check boxes (right) showing properties for a multiple selection of files in Nautilus (left)

  Check boxes showing the Hidden, Readable and Writeable states of two selected files in Nautilus. Both files are hidden, neither are writeable, but one is readable. The Readable check box is therefore shown in its mixed state.

  In this example, both selected files are hidden (since their filenames start with "."), and the emblems on their icons show that neither file is writeable, but one is readable. The Readable check box is therefore shown in its mixed state.
  .

  When a check box is in its mixed state:

  - clicking the box once should check the box, applying that setting (when confirmed) to all the selected objects

  - clicking the box a second time should uncheck the box, removing that setting (when confirmed) to all the selected objects

  - clicking the box a third time should return the box to its mixed state, restoring each selected object's original value for that setting (when confirmed)

- Label a group of check boxes with a descriptive heading above or to the left of the group.

- Use a frame around the group if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.

- Do not place more than about eight check boxes under the same group heading. If you need more than eight, try to use blank space, heading labels or frames to divide them into smaller groups. Otherwise, consider using a check box list instead— but you probably also need to think about how to simplify your user interface.

- Try to align groups of check boxes vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular alignments only if they greatly improve the layout of the window.

### Radio Buttons

Radio buttons are used in groups to select from a mutually exclusive set of options. Only one radio button within a group may be set at any one time. As with check boxes, do not use radio buttons to initiate actions.

#### A typical group of radio buttons

A typical group of three radio buttons in a dialog

#### Diretrizes

- Only use radio buttons in groups of at least two, never use a single radio button on its own. To represent a single setting, use a check box or two radio buttons, one for each state.

- Exactly one radio button should be set in the group at all times. The only exception is when the group is showing the properties of a multiple selection, when one or more of the buttons may be in their mixed state.

- Do not initiate an action when the user clicks a radio button. However, if used in an instant-apply property or preference window, update the setting represented by the radio button immediately.

- Clicking a radio button should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.

- If toggling a radio button affects the sensitivity of other controls, place the radio button immediately to the left of the controls that it affects. This helps to indicate that the controls are dependent on the state of the radio button.

- Use sentence capitalization for radio button labels, for example Switched movement. Provide an access key in the label that allows the user to set the radio button directly from the keyboard.

- If the radio button represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the radio button in its mixed state. For example:

  #### Radio buttons (right) showing properties for a multiple selection of shapes in a drawing application (left)

  Radio buttons showing the Thick, Thin and Dashed drawing styles of two selected shapes in a drawing application. One shape is drawn in the thick style, the other in the dashed style. The Thick and Dashed radio buttons are therefore shown in their mixed state, and the Thin radio button is unset.

  . In this situation, clicking any radio button in the group should set the clicked button, and unset all the others. Thereafter, the group should behave like a normal radio button group— there is no way to reset a radio button to its mixed state by clicking on it. Provide a Reset button or equivalent in the window that allows the previous mixed settings to be restored without closing the window or cancelling the dialog.

- Label a group of radio buttons with a descriptive heading above or to the left of the group.

- Use a frame around the group if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.

- Do not place more than about eight radio buttons under the same group heading. If you need more than eight, consider using a single-selection list instead— but you probably also need to think about how to simplify your user interface.

- Try to align groups of radio buttons vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular alignments only if they greatly improve the layout of the window.

### Toggle Buttons

Toggle buttons look similar to regular Buttons, but are used to show or change a state rather than initiate an action. A toggle button's two states, set and unset, are shown by its appearing "pushed in" or "popped out" respectively.

#### A typical group of toggle buttons

A group of four toggle buttons representing a choice of measurement units: inches, centimeters, feet and meters

#### Diretrizes

- Do not use groups of toggle buttons in dialogs unless space constraints force you to do so, or you need to provide consistency with a toolbar in your application. Check boxes or radio buttons are usually preferable, as they allow more descriptive labels and are less easily-confused with other types of control.

- Only use toggle buttons in groups, so they are not mistaken for regular buttons. Make the group behave like either a group of check boxes or a group of radio buttons, as required.

- Provide an access key in the label of all toggle buttons that allows the user to set or unset the button directly from the keyboard.

- Label a group of toggle buttons with a descriptive heading above or to the left of the group, as you would with a group of check boxes or radio buttons.

- Use a frame around the group of buttons if necessary, but remember that blank space often works just as well and results in a less visually-cluttered dialog.

- Try to align groups of toggle buttons horizontally rather than vertically. This is how toggle buttons normally appear on a toolbar, so the user will be more familiar with this arrangement.

- Do not leave any space between toggle buttons in a group, otherwise they may look unrelated or may be mistaken for regular buttons.

- Use header capitalization for toggle button labels, for example No Wallpaper, Embossed Logo.

- If your toggle button can display text, an icon, or both, choose which to display at runtime according to the user's setting in the GNOME Menus and Toolbars preference dialog.

- Use the same text or graphical label for a toggle button whether it is set or unset.

- If the toggle button represents a setting in a multiple selection that is set for some objects in the selection and unset for others, show the button in its mixed state. For example:

  #### Toggle buttons (right) showing properties for a multiple selection of shapes in a drawing application (left)

  Toggle buttons showing the Thick, Thin and Dashed drawing styles of two selected shapes in a drawing application. One shape is drawn in the thick style, the other in the dashed style. The Thick and Dashed toggle buttons are therefore shown in their mixed state, and the Thin toggle button is unset.

### Drop-down Lists

Drop-down lists are used to select from a mutually exclusive set of options. They can be useful when there is insufficient space in a window to use a group of radio buttons or a single-selection list, with which they are functionally equivalent.

#### A drop-down list showing current selection (left) and the list of available choices when clicked on (right)

Two images, one of a drop-down list displaying its current setting, and the other showing its popup menu of available choices when clicked on

Recommendations:

- Do not use drop-down lists with fewer than three items, or more than about ten. To offer a choice of two options, use radio buttons or toggle buttons. To offer a choice of more than ten options, use a list.

- Do not initiate an action when the user selects an item from an drop-down list. However, if used in an instant-apply property or preference window, update the setting that the menu represents immediately.

- Selecting an item from a drop-down list should not affect the values of any other controls. It may sensitize, insensitize, hide or show other controls, however.

- Label the drop-down list with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the drop-down list.

- Use sentence capitalization for drop-down list items, for example Switched movement

- Assign an access key to every drop-down list item. Ensure each access key is unique within the enclosing window or dialog, not just within the menu.

- Do not assign shortcut keys to drop-down list items by default. The user may assign their own shortcut keys in the usual way if they wish, however.

- Do not use a drop-down list in a situation where it may have to show a property of a multiple selection, as drop-down lists have no concept of mixed state. Use a group of radio or toggle buttons instead, as these can show set, unset or mixed states.

- Do not use submenus on a drop-down list.

You should normally use radio buttons or a list instead of drop-down lists, as those controls present all the available options at once without any further interaction. However, drop-down lists may be preferable in a window where:

- there is little available space

- the list of options may change over time

- the contents of the hidden part of the menu are obvious from its label and the one selected item. For example, if you have an option menu labelled "Month:" with the item "January" selected, the user might reasonably infer that the menu contains the 12 months of the year without having to look.

Drop-down lists can also be useful on toolbars, to replace a group of several mutually-exclusive toggle buttons.

### Drop-down Combination Boxes

Drop-down combination boxes combine a text entry field and a drop-down list of pre-defined values. Selecting one of the pre-defined values sets the entry field to that value.

#### A drop-down combination box before and after its drop-down list is displayed

Two images, one of a drop-down combination box entry field displaying its current selection, and the other showing its drop-down list of available choices when clicked on

#### Diretrizes

- Only use a drop-down combination box instead of a list, drop-down list or radio button group when it is important that the user be able to enter a new value that is not already amongst the list of pre-defined choices.

- Do not initiate an action when the user selects an item from the list in a drop-down combination box. If used in an instant-apply property or preference window, update the setting represented by the drop-down combination box immediately if possible. If this isn't possible due to the contents of the entry field being invalid while the user is still typing into it, update the related setting when the drop-down combination box loses focus instead.

- If the user types a value into the drop-down combination box that is not already in the drop-down list, add it to the list when the drop-down combination box loses focus so they can select it next time.

- Interpret user input into a drop-down combination box in a case-insensitive way. For example, if the user types `blue`, `Blue` and `BLUE` into the same drop-down combination box on different occasions, only store one of these in the combo's drop-down list, unless your application makes a distinction between the different forms (which is usually a bad idea).

- Label the drop-down combination box with a text label above it or to its left, using sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the drop-down combination box.

- Use sentence capitalization for the drop-down list items, for example Switched movement.

### Scrollbars

Often an object (such as a document or a list) will not be fit within the confines of its viewer control. In these cases a scrollbar can be affixed to the viewer control. The scrollbar alters which part of the object is currently visible inside the viewer control: it slides the view across the object in one axis (horizontal or vertical).

#### Diretrizes

- Only display scrollbars when they are required for sliding the view. If an object fits inside the viewer control, don't draw scrollbars. If you are using a GtkScrolledWindow, call `gtk_scrolled_window_set_policy` setting the appropriate axis (or axes) to GTK_POLICY_AUTOMATIC.

- Do not use scrollbars as a replacement for a slider. Scrollbars should only be used affixed to a view that they actively alter, not used as a generic continuous input control.

- Affix scrollbars to the right side of a viewer control (to slide the view vertically), or to the bottom side (to slide the view horizontally). Do not affix scrollbars on the top or left sides of a viewer control.

- Scrollbars should be aligned in both directions with the view they are affixed to on the axis they control. In other words, horizontal scrollbars should span the full length of the viewer control, and vertical scrollbars should span the full height of the viewer control.

- If both horizontal and vertical scrollbars are acting upon a view, alignment will require that small rectangle in the lower right corner where the horizontal and vertical scrollbars meet will be blank. This is OK.

- Scrollbars should affect the view to which they are affixed in realtime: as the user drags or clicks the view should change. Time lag will be disconcerting and negatively impact a users ability to navigate content inside the view.

### Lists

A list control allows the user to inspect, manipulate or select from a list of items. Lists may have one or more columns, and contain text, graphics, simple controls, or a combination of all three.

#### A simple two column list

Picture of list control containing two unsorted columns of text

#### Diretrizes

- Always give list controls a label, positioned above or to the left of the list, in sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the list.

- Make the list control large enough that it can show at least four items at a time without scrolling. For lists of ten or more items, increase this minimum size as appropriate.

- If the list appears in a dialog or utility window, consider making the window and the list within it resizable so that the user can choose how many list items are visible at a time without scrolling. Each time the user opens this dialog, set its dimensions to those that the user last resized it to.

- Do not use lists with less than about five items, unless the number of items may increase over time. Use check boxes, radio buttons or an drop-down list if there are fewer items.

- Only use column headers when:

  - the list has more than one column, or

  - the list has only one column, but the user may wish to re-order the list. (This is rarely useful with single column lists).

  In most other situations, column headers take up unnecessary space, and the extra label adds visual clutter.

- Always label column headers when used. If the column is too narrow for a sensible label, provide a tooltip for the column instead. Apart from its obvious use, this will help ensure that assistive technologies can describe the use of the column to visually impaired users.

- Consider using a check box list for multiple-selection lists, as these make it more obvious that multiple selection is possible:

  #### A simple check box list

  Picture of list control with two columns. The first column consists of check boxes showing whether or not the corresponding item in the second column is selected for further action.

  If you do this, you should normally set the list control itself to be single-selection, but this depends on the particular task for which it will be used.

- For multiple selection lists, show the number of items currently selected in a static text label below the list, for example, Names selected: 3. Such a label also makes it more obvious that multiple selection is possible.

- Consider providing Select All and Deselect All buttons beside multiple selection lists, if appropriate.

#### Sortable Lists

Users often prefer to sort long lists, either alphabetically or numerically, to make it easier to find items. Allow users to sort long or multi-column lists by clicking on the column header they want to sort.

##### Diretrizes

- Indicate which column is currently sorted by showing an upward or downward facing arrow in its header:

  Sort Order | Arrow Direction | Example
  --- | --- | ---
  Natural | Down | Alphabetical; smallest number first; earliest date first; checked items first
  Reverse | Up | Reverse alphabetical; largest number first; most recent date first; unchecked items first)

- Clicking an unsorted column header sorts the column in natural order, indicated by showing a down arrow in its header.

- Clicking a column header sorted in natural order re-sorts it in reverse order, indicated by showing an up arrow in its header.

  ##### Un-sorting lists

  Occasionally, an unsorted state may be useful, for example to show items in the order in which the user added them to the list. In such cases, clicking a column sorted in reverse order should un-sort it, indicated by removing the arrow from the column header.

  Usually, however, this is better achieved by adding an extra column that the user can sort in the usual way, such as a sequence number column in this example.

### Trees

A tree control allows the user to inspect, manipulate or select from a hierarchichal list of items. Trees may have one or more columns, and contain text, graphics, simple controls, or a combination of all three.

#### Use trees with care!

Because of their complexity compared to other controls, novice and some intermediate users often have problems using and understanding tree controls. If your application is designed for that type of user, you might want to consider alternative ways of presenting the information, such as the Nautilus list or icon view, or the hierarchical browser lists found in GNUstep's File Viewer.

#### A simple tree control with one level of hierarchy

Picture of tree control showing months of the year as top level nodes, and public holidays in those months as their children

#### Diretrizes

- Always give tree controls a label, positioned above or to the left of the tree, in sentence capitalization. Provide an access key in the label that allows the user to give focus directly to the tree.

- Use column headers when:

  - the tree has more than one column

  - the tree has only one column, but the user may wish to re-order the tree. This should rarely be true of single column trees.

  In most other situations, column headers take up unnecessary space, and the extra label adds visual clutter.

- Always label column headers when used. If the column is too narrow for a sensible label, provide a tooltip for the column instead. Apart from its obvious use, this will help ensure that assistive technologies can describe the use of the column to visually impaired users.

- Consider using a check box tree for multiple-selection trees, as these make it more obvious that multiple selection is possible:

  #### A simple check box tree

  Picture of tree control with two columns. The first column consists of check boxes showing whether or not the corresponding item in the second column is selected for further action.

  If you do this, you should normally set the tree control itself to be single-selection, but this depends on the particular task for which it will be used.

- For multiple selection trees, show the number of items currently selected in a static text label below the tree, for example, Names selected: 3. Such a label also makes it more obvious that multiple selection is possible.

- Consider providing Select All and Deselect All buttons beside multiple selection trees, if appropriate to the task.

#### Sortable Trees

As with lists, the user may find it useful to sort long or multi-column trees. See the guidelines in for more information.

### Tabbed Notebooks

A tabbed notebook control is a convenient way of presenting related information in the same window, without having to display it all at the same time. It is analogous to the divider tabs in a ring binder or a file cabinet.

#### A typical notebook control with three tabs

Picture of notebook control with three tabs

#### Diretrizes

- Do not put too many pages in the same notebook. If you cannot see all the tabs without scrolling or splitting them into multiple rows, you are probably using too many and should use a list control instead. See the example below.

- Label tabs with header capitalization, and use nouns rather than verbs, for example Font or Alignment. Try to keep all labels in a notebook the same general length.

- Do not assign access keys to tab labels, as this means you cannot use those access keys for any other control on any of the notebook pages without conflict. Even if you are able to assign access keys that would not conflict, it is better not to as it may be impossible to avoid the conflict when your application is translated to other languages. Assign an access key to every other control on each page, however.

- Do not design a notebook such that changing controls on one page affects the controls on any other page. Users are unlikely to discover such dependencies.

- If a control affects only one notebook page, place it on that notebook page. If it affects every page in the notebook, place it outside the notebook control, for example beside the window's OK and Cancel buttons.

- Use tabs that are proportional to the width of their labels. Don't just set all the tabs to the same width, as this makes them harder to scan visually, and limits the number of tabs you can fit into the notebook without scrolling. For example:

  #### Fixed- and proportional-width tabs (preferred)

  Side-by-side comparison of one notebook whose tabs are all the same width, and one whose tabs are only wide enough to accommodate the tab labels. The latter takes up around 33% less screen space.

- Although the contents of each page in a notebook will take up a different amount of space, do not use larger than normal spacing around the controls in the "emptier" pages, and do not center the controls on the page.

- If your tab labels include icons, choose whether or not to show the icons at runtime based on the user's preference in the GNOME Menus and Toolbars desktop preferences dialog. Always show the text part of the label, however.

If you have more than about six tabs in a notebook, use a list control instead of tabs to switch between the pages of controls. For example:

#### Use of list control where there would be too many tabs to fit comfortably in a notebook

Part of a window including a list control with 7 items, each item representing a category of settings such as "Appearance" and "Navigation". The controls in the rest of the window change depending on which item is selected in the list.

As in this example, place the list control on the left-hand side of the window, with the dynamic portion of the window immediately to its right.

#### Status Indicators

In some tabbed windows, such as preference windows, it might be desirable to indicate the status of a particular tab. This can be used to notify the user that a web page that is still loading or has been loaded, a new message is waiting in a particular instant messaging conversation, or that a document has not been saved. Such a status indicator should be an icon that is placed directly to the left of the tab label. Additionally, the tab label's color might be changed to indicate a certain status. Do not simply rely on a different coloring scheme for status indication.

### Progress Bars

Progress bars are visual indicators of the progress of a task being carried out by the application, and provide important feedback. For information on using a progress bar within a progress window, see .

You can use two main types of progress bars in your application— measured-progress bars and indeterminate-progress bars (the kind that bounce back and forth). In addition there are three types of measured progress bars.

#### Diretrizes

- Always use a measured progress bar when the length of a task can be precisely or approximately predicted. Otherwise, use an indeterminate progress indicator or a checklist window.

- Ensure that a measured-progress bar measures an operation's total time or total work, not just that of a single step. An exception is a progress bar that measures the total time or work of the current step in a progress checklist.

#### Time-remaining Progress Indicator

An animation consisting of a bar whose changing length indicates how much time remains in an operation, and text stating how much time remains before the operation will be complete. Time-remaining bars are the most useful type of progress bar.

##### A simple 'time remaining' progress bar

A simple time-remaining progress dialog

Use a time-remaining bar if your application will display an initial estimate of an operation's remaining time and then periodically display updated estimates. Each updated estimate should be based on changes that have occurred and that will cause the operation to finish more quickly or more slowly. If the operation will finish more slowly, your application can display an updated estimate that is greater than the estimate previously displayed.

#### Typical-time Progress Indicator

A bar whose changing length indicates how much time remains if an operation takes as long as it typically does. Typical-time bars are the least precise type of measured-progress bar, but they are more useful than indeterminate-progress bars.

##### A simple 'typical time remaining' progress bar

A simple 'typical time remaining' progress dialog

For some operations, you cannot estimate the time remaining or the proportion of work completed. However, if you can estimate the typical time for that operation, you can provide feedback with a typical-time bar.

If your application overestimates the completed amount of work, the length of the bar can indicate "almost complete" until the operation is complete. If your application underestimates how much work is complete, the application can fill the remaining portion of the bar when the operation is complete.

#### Indeterminate-progress indicator

An animated bar indicating only that an operation is ongoing, not how long it will take. One example is the "throbber" in a web browser. Indeterminate-progress bars are the least precise type of progress bar.

##### A simple 'indeterminate time' progress bar; the slider moves from left-to-right and back again until the operation is complete

A simple 'indeterminate time' progress dialog, showing a slider moving back and forth until the operation is complete

Use an indeterminate-progress bar to provide feedback only for operations whose duration you cannot estimate at all.

### Statusbars

A statusbar is an area at the bottom of a window that can be used to display brief information about the status of the application.

#### A simple statusbar

A statusbar at the bottom of a document window, showing current zoom level and a status message indicating that the document has been modified since it was last saved

#### Diretrizes

- Use statusbars only in application or document windows. Do not use them in dialogs, alerts or other secondary windows.

- Only place a statusbar along the bottom of a window.

- Only use statusbars to display non-critical information. This might include:

  - general information about the document or application. For example, current connection status in a network application, or the size of the current document in a text editor.

  - information about the task the user is currently performing. For example, while using the selection tool in a drawing application, "Hold Shift to extend the selection"

  - progress of a background operation. For example, "Sending to printer", "Printing page 10 of 20", "Printing Complete".

  - a description of the control or area of the window under the mouse pointer. For example, "Drop files here to upload them"

  Remember that statusbars are normally in the user's peripheral vision, and can even be turned off altogether using the application's View Status Bar menu item. The user may therefore never see anything you display there, unless they know when and where to look for it.

- When there is no interesting status to report, leave a status bar panel blank rather than displaying something uninformative like "Ready". This way, when something interesting does appear in the statusbar, the user is more likely to notice it.

- If you want to make all or part of your statusbar interactive, use the following conventions:

  - Inlaid appearance for areas that respond to a double click

  - Flat appearance for areas that are not interactive

  In , the appearance indicates that the left area would respond to a double click (perhaps by saving the document), and the progress indicator on the right is non-interactive.

  #### An interactive statusbar

  A statusbar with a text panel that responds to a double click, a button that responds to a single click, and a non-interactive progress area

  Ensure that double-clicking in the status area does not provide any functionality that is not also available in the main application menu bar, or by some other accessible means.

- Provide a drag handle in the bottom right corner of the status bar of resizeable windows. Subclasses of GtkStatusbar should use the drag handle provided by that class. A reimplementation of a status bar, which is discouraged, should also reimplement the GtkStatusbar drag handle in both appearance and function.

### Frames and Separators

A frame is a box with a title that you can draw around controls to organise them into functional groups. A separator is a single horizontal or vertical line that you can use to divide windows into functional groups.

Frames with a border around their perimeter have traditionally been used for denoting groups of related controls. This is advantageous because it physically separates dissimilar controls, and also avoids repetition of the frame's label in individual member control labels. Unfortunately, they add visual noise that can both make a window appear more complex than it really is, and reduce the ability to quickly scan window elements.

Rather than using bordered frames, use frames without borders, bold labels to make the categories stand out, and indented contents. This, combined with good layout and spacing, is usually a better alternative to bordered frames.

#### Preferred frame style, using bold labels, spacing and indentation

Frame showing the preferred style described above

#### Traditional frame style, using borders (deprecated)

Frame showing the traditional style described above

#### Diretrizes

- Before you add a frame with a visible border or separator to any window, consider carefully if you really need it. It is usually better to do without, if the groups can be separated by space alone. Do not use frames and separators to compensate for poor control layout or alignment.

- Do not mix framed and unframed groups in the same window.

- Do not nest one frame inside another. This results in visual clutter.

- If all the items in a group are disabled, disable the group title too.

## Feedback

### Characteristics of Responsive Applications

Although highly responsive applications can differ widely from one another, they share the following characteristics:

- They give immediate feedback to users, even when they cannot fulfill their requests immediately.

- They handle queued requests as users would expect, discarding requests that are no longer relevant and reordering requests according to users' probable priorities.

- They let users do other work while long operations proceed to completion— especially operations not requested by users— such as reclaiming unused memory or other "housekeeping" operations.

- They provide enough feedback for users to understand what they are doing, and organize feedback according to users' abilities to comprehend and react to it.

- They let users know when processing is in progress.

- They let users know or estimate how long lengthy operations will take.

- They let users set the pace of work, when possible, and they let users stop requested tasks that have started but not finished.

Highly responsive applications put users in control by quickly acknowledging each user request, by providing continuous feedback about progress toward fulfilling each request, and by letting users complete tasks without unacceptable delays.

Even applications with attractive, intuitive user interfaces can lack responsiveness. Typically, unresponsive applications have at least one of the following problems:

- They provide late feedback— or no feedback— for users' requests, leaving users wondering what the application has done or is doing.

- When performing extended operations, they prevent users from doing other work or cancelling the extended operation.

- They fail to display estimates of how long extended operations will last, forcing users to wait for unpredictable periods.

- They ignore users' requests while doing unrequested "housekeeping", forcing users to wait at unpredictable times— often without feedback.

You can sometimes possible to improve an application's responsiveness without speeding up the application's code. For tips on how to make such improvements, see .

### Acceptable Response Times

Some user interface events require shorter response delays than others. For example, an application's response to a user's mouse click or key press needs to be much faster than its response to a request to save a file. The table below shows the maximum acceptable response delay for typical interface events.

#### Maximum acceptable response times for typical events

UI Event | Maximum Acceptable Response Time
--- | ---
Mouse click, pointer movement, window movement or resizing, keypress, button press, drawing gesture, other UI input event involving hand-eye co-ordination | 0.1 second
Displaying progress indicators, completing ordinary user commands (e.g. closing a window), completing background tasks (e.g. reformatting a table) | 1.0 second
Displaying a graph or anything else a typical user would expect to take time (e.g. displaying a new list of all a company's financial transactions for an accounting period) | 10.0 seconds
Accepting and processing all user input to any task | 10.0 seconds

Make each response delay in your application as short as possible, unless users need time to see the displayed information before it is erased. The acceptable response delay for each event is based on a typical user's sense that the event is a logical point at which to stop or pause. The greater that sense is, the more willingly the user will wait for a response. Verify that your application responds to users' requests within the limits listed in the table above. If your application cannot respond within those limits, it probably has one or more general problems caused by a particular algorithm or module.

#### Diretrizes

- Verify that your application provides feedback within 100 milliseconds (0.1 second) after each key press, movement of the mouse, or other physical input from the user.

- Verify that your application provides feedback within 100 milliseconds (0.1 second) after each change in the state of controls that react to input from the user— for example, displaying menus or indicating drop targets.

- Verify that your application takes no longer than 1 second to display each progress indicator, complete each ordinary user command, or complete each background task.

- Verify that your application takes no longer than 10 seconds to accept and process all user input to any task—including user input to each step of a multistep task, such as a wizard.

### Responding to User Requests

If your application takes too long to respond, users will become frustrated. Use these techniques to improve the responsiveness of your application.

#### Diretrizes

- Display feedback as soon as possible.

- If you cannot display all the information that a user has requested, display the most important information first.

- Save time by displaying approximate results while calculating finished results.

- If users are likely to repeat a time-consuming command in rapid succession, save time by faking the command's effects instead of repeatedly processing the command. For example, if a user adds several rows to a table stored in a database, you might display each new row immediately but delay actually creating each new row in the database until the user finished adding all the rows.

- Work ahead. Prepare to perform the command that is most likely to follow the current command. That is, use idle time to anticipate users' probable next requests. For example, as the user of an email application reads the currently displayed new message, the application might prepare to display the next new message.

- Use background processing. Perform less important tasks —such as housekeeping— in the background, enabling users to continue working.

- Delay work that is not urgent. Perform it later, when more time is available.

- Discard unnecessary operations. For example, to move back several pages in a web browser, a user might click the browser's Back button several times in rapid succession. To display the final requested page more quickly, the browser might not display the pages visited between the current page and that final page.

- Use dynamic time management. At run time, change how your application prioritizes user input and other processing, based on the application's current state. For example, if a user is typing text in one word-processing document while printing another, the word-processing application might delay the printing task if the user shifts to an editing task (such as cutting and pasting text) that requires greater resources.

- In your application, display an estimate of how long each lengthy operation will take.

  - If a command might take longer than 5 seconds to complete its work on an object, allow users to interact with any parts of the object and parts of the application that are not directly affected by the command.

  - If a command provides lengthy output, show partial results as they become available. Scroll the results (if necessary) until the user moves input focus to a component (e.g. a scrollbar or text area) involved in the scrolling.

### Types of Visual Feedback

You can use two types of visual feedback for operations in your application— pointer feedback and progress animations.

#### Pointer Feedback

Pointer feedback changes the shape of the pointer. For example, a busy pointer indicates that an operation is in progress and that the user cannot do other tasks. A busy-interactive pointer indicates that an operation is in progress but the window is still interactive.

##### Busy pointer (left) and Busy-Interactive pointer (right)

Busy pointer (left) and busy-interactive pointer (right)

#### Progress Animations

Progress animations show either how much of an operation is complete, or only that an operation is ongoing. Normally, these take the form of either a progress bar or a progress checklist.

##### Diretrizes

- When displaying a progress animation, open it as soon as possible after you know it is required, and close it automatically as soon as the associated operation is complete.

- Use a measured-progress bar if your application can estimate either how long the operation will take, or what proportion of the operation is complete.

- If your application can make neither estimate, and the operation only has one step, use an indeterminate-progress bar. For operations with two or more steps, use a progress checklist that dynamically displays a check mark for each completed step.

##### Progress Bars

For information on different types of progress bars and when to use them see .

###### Progress Windows vs. the Statusbar

In an application where the primary windows contain a status bar (which in turn contains a progress bar), it will often be the case that an operation's feedback could be presented in either the statusbar or a progress window. A rule of thumb is to use the statusbar when an operation is expected to take fewer than ten seconds, otherwise use a progress window. However, do consider the following when choosing between the two:

- Opening a new window, particularly when an operation is short, can needlessly disrupt the user's workflow.

- Progress windows can convey more information.

- Multiple progress windows can be open at once, whereas only a single operation can be presented in a statusbar.

- Progress windows provide a Cancel button.

##### Checklist Windows

A checklist window shows the sequence of stages in an operation. See .

###### A Checklist Window

A checklist window showing a sequence of steps

### Choosing Appropriate Feedback

To determine which type of visual feedback to provide for a particular operation, consider these factors:

- Whether your application can provide an estimate of the operation's progress.

- Whether the operation blocks the user from issuing further commands in your application.

- Whether your application has a dedicated space, such as a status bar, for indicating the status of operations.

The table below shows which type of feedback to provide for operations that usually take at least 1 second to finish. In the "Appropriate Feedback" column, "Internal progress animations" means progress animations displayed in an application's dedicated status area, and "External progress animations" means progress animations displayed somewhere other than in a dedicated status area— typically, in an alert box.

#### Visual feedback types for operations that take at least 1 second

Typical Duration > 5 seconds? | User blocked from issuing further commands? | Application has dedicated status area? | Appropriate feedback
--- | --- | --- | ---
Sim | Sim | Sim | Internal animation plus pointer feedback
Sim | Sim | Não | Pointer feedback
Sim | Não | Sim | Internal animation
Não | Sim | Sim | Internal animation plus pointer feedback
Não | Sim | Não | External animation plus pointer feedback
Não | Não | Sim | Internal animation
Não | Não | Não | External animation

#### Diretrizes

- Use a busy pointer whenever users are blocked from interaction with your application for 1 second or longer. Display the busy pointer less than 1 second after the operation begins.

- If a command will likely take 10 seconds or longer to finish, provide a Stop or Cancel button, which can also be activated by pressing Esc, that lets users terminate the command's processing even if your application cannot undo the command's effects. See .

- When using an external animation, leave the window containing the animation on-screen for at least 1 second after the operation has completed, with a successful completion message. Change the Stop or Cancel button to an OK button during this period— pressing this button should close the window immediately.

### Allowing Interruptions

Users sometimes need to stop a command— for example, because it is taking too long. Your application should let users stop commands in progress, even if stopping a command cannot undo or "roll back" all the command's effects.

#### Diretrizes

- Place a Stop or Cancel button, which can also be activated by pressing Esc, near the progress animation for the interruptable command.

- Label the button Cancel if the whole operation can be cleanly abandoned with no side effects, leaving the system in the state it was in prior to the operation beginning. Terminate the command immediately when the user presses this button.

- Label the button Stop if the command can be interrupted, but its effects up to that point cannot (or should not) be reversed. When the user presses this button, open an alert box that warns of the potential side effects of stopping the command. The alert box should have only two buttons: one for continuing the command's processing, and one for immediately terminating it.

Alternatively, you can place the Stop or Cancel button near the control with which the user issued the command that needs to be stopped. Place the button here only if:

- There is no progress animation for the command, or

- The progress animation is in a window's status area or in another location that lacks space for a Stop or Cancel button.

In the alert box that appears after pressing a Stop button, ensure the message and button labels in the alert box are specific and precise. Ambiguous button labels can cause users to terminate or continue a command unintentionally. For example, use:

    Continue deleting files? [Continue Deleting]
        [Stop Deleting]

rather than

    Operation interrupted, continue? [Yes]
        [No]

since in the latter example, it is not clear whether pressing Yes would continue the operation or continue the interruption (i.e. cancel the operation).

## Visual Design

Visual design is not just about making your application look pretty. Good visual design is about communication. A well-designed application will make it easy for the user to understand the information that is being presented, and show them clearly how they can interact with that information. If you can achieve all that, your application will look good to the user, even if it doesn't have any fancy graphics or spinning logos!

### Color

Color is a good tool for communicating information in a user interface. For example, it can be used to:

- strengthen a desktop's look and feel by enhancing a theme

- accent a dynamic alert in a system management application

- emphasize an element in a long list to expedite scanning

- add aesthetically pleasing details to an icon

However, color should always be regarded as a useful addition to your design, not as a necessity. Never depend upon colors alone to display important information, and keep in mind that if colors cannot be perceived correctly (for example, the user has an 8-bit system, or is color-blind), your application should still be usable.

#### Palette

A 32-color palette has been developed for the GNOME desktop. The palette may be downloaded from http://developer.gnome.org/projects/gup/images/ximian-palette. To use it in The GIMP, save it to your `~/.gimp_1.2/palettes` folder, and restart The GIMP. A single, consistently-used palette helps give a unified look and feel to the desktop while minimizing visual distractions. If you need a color that is darker or lighter than the colors in this basic palette (e.g., for anti-aliasing), choose a color that is closest to the hue you need, then darken or lighten as required.

##### The basic GNOME 32-color palette

The basic GNOME 32-color palette

##### RGB and hexadecimal values for the basic palette

Color | Description | RGB | Hex | Color | Description | RGB | Hex
--- | --- | --- | --- | --- | --- | --- | ---
| Basic 3D Hilight | 234 232 227 | #EAE8E3 |  | Basic 3D Medium | 186 181 171 | #BAB5AB
| Basic 3D Dark | 128 125 116 | #807D74 |  | 3D Shadow | 86 82 72 | #565248
| Green Hilight | 197 210 200 | #C5D2C8 |  | Green Medium | 131 166 127 | #83A67F
| Green Dark | 93 117 85 | #5D7555 |  | Green Shadow | 68 86 50 | #445632
| Red Hilight | 224 182 175 | #E0B6AF |  | Red Medium | 193 102 90 | #C1665A
| Red Dark | 136 70 49 | #884631 |  | Red Shadow | 102 56 34 | #663822
| Purple Hilight | 173 167 200 | #ADA7C8 |  | Purple Medium | 136 127 163 | #887FA3
| Purple Dark | 98 91 129 | #625B81 |  | Purple Shadow | 73 64 102 | #494066
| Blue Hilight | 157 184 210 | #9DB8D2 |  | Blue Medium | 117 144 174 | #7590AE
| Blue Dark | 75 105 131 | #4B6983 |  | Blue Shadow | 49 78 108 | #314E6C
| Face Skin Hilight | 239 224 205 | #EFE0CD |  | Face Skin Medium | 224 195 158 | #E0C39E
| Face Skin Dark | 179 145 105 | #B39169 |  | Face Skin Shadow | 130 102 71 | #826647
| Accent Red | 223 66 30 | #DF421E |  | Accent Red Dark | 153 0 0 | #990000
| Accent Yellow | 238 214 128 | #EED680 |  | Accent Yellow Dark | 209 148 12 | #D1940C
| Accent Green | 70 160 70 | #46A046 |  | Accent Green Dark | 38 199 38 | #267726
| White | 255 255 255 | #ffffff |  | Black | 0 0 0 | #000000

#### Hue, Brightness, Contrast

Users with vision disorders, such as color-blindness or low vision, require alternatives to default settings. A good user interface anticipates these needs by providing customizable preferences and support for accessible themes. Even better is an application that is already configured with carefully-chosen color and contrast defaults.

An estimated 11% of the world population has some sort of color-blindness. Those affected typically have trouble distinguishing between certain hues such as red and green (deuteranopia or protanopia), or blue and yellow (tritanopia). Therefore it is necessary to allow the user to customize colors in any part of your application that conveys important information. This means that your application must effectively convey information using just the colors from any theme that the user chooses.

A useful tool for reviewing information about color-blindness and checking legibility of images for color-blind users is Vischeck, an online tool that simulates the way an image or a website might appear to a user who has deuteranopia, protanopia, or tritanopia.

##### How the earth looks to a user with normal color vision (left), deuteranopia (middle), and tritanopia (right). (Images from http://www.vischeck.com).

Photo of earth as a normally-sighted user would see it | Photo of earth as a user with red-green color-blindness would see it | Photo of earth as a user with blue-yellow color-blindness would see it

Other users have more problems with contrast levels rather than hue on their screen. Some users require a high level of contrast between background and foreground colors, such as black on white, white on black, or some other high-contrast combination. Others can experience discomfort unless they use low-contrast settings, such as gray text on a lighter gray background.

You can meet these needs by ensuring your application supports the accessible GNOME themes (found in the gnome-themes module in cvs), which include high and low contrast themes, and large print themes. This means you must supply default and large sizes of high-, low- and regular-contrast icon sets with your application.

##### Diretrizes

- Use the GNOME color palette. If you need a darker or lighter shade, start from one of the colors from the palette and darken or lighten as needed.

- Do not use color as the only means to distinguish items of information. All such information should be provided by at least one other method, such as shape, position or textual description.

- Ensure your application is not dependent on a particular theme. Test it with different themes, especially high and low contrast accessibility themes, which use fewer colors, to ensure your application respects the settings. For example, all text should appear in the foreground color against the background color specified in the chosen theme.

- Select colors carefully. When they need to be recognizably different, select the light colors from orange, yellow, green or blue-green, and darker colors from blue, violet, purple or red, as most people affected by color-blindness already see blue, violet, purple and red as darker than normal.

### Window Layout

#### General

Placement of visual components in an application is important because relationships between elements are indicated by their positions. This is called "layout" in interface design.

A clean layout is crucial to creating a smooth visual flow of information for the user. This section describes the proper component placement and spacing to use in GNOME applications. The major components discussed will be labels, icons, radio buttons and check boxes, text fields, command buttons, and drop-down menus.

#### Dialogs

When a user is scanning a complex preferences dialog consisting of many labels and corresponding check boxes, text fields, and drop-down combination boxes, it is easy to see how she can quickly become hindered by poor layout in the visual design. For information on laying out Alerts, see

##### Improved window layout

Initial layout with poor alignment and limited use of white space | Improved layout with fewer alignment points, frames removed to relieve clutter, and clearer grouping with use of white space

In , the dialog on the left presents labels which are not left-aligned. The user's eye is not given a proper anchor to scan the dialog quickly.

As the labels are all similar in length, they should be left-aligned. Now the user has a firm left margin to anchor the eye and scan the list of items vertically more easily. If most of the labels in a group greatly differ in length, right-align them instead, so that the controls do not end up too far away from their corresponding labels.

Using frames with visible borders to separate groups within a window is deprecated. Use spacing and bold headers instead. This is more effective because there are fewer gratuitous lines to distract the user from the main content in the window. See for more details.

Try to keep components consonant with each other in terms of size and alignment. This is particularly important within a group of controls, so that the user's ability to quickly scan information is not sacrificed. Minimize as much as possible the need for the user's eye to jump around when scanning a layout.

##### Layout specifications

Improved layout with fewer alignment points, frames removed to relieve clutter, and clearer grouping with use of white space

##### Diretrizes

- Leave a 12-pixel border between the edge of the window and the nearest controls.

- Leave a 12-pixel horizontal gap between a control and its label. (The gap may be bigger for other controls in the same group, due to differences in the lengths of the labels.)

- Labels must be concise and make sense when taken out of context. Otherwise, users relying on screenreaders or similar assistive technologies will not always be able to immediately understand the relationship between a control and those surrounding it.

- Assign access keys to all editable controls. Ensure that using the access key focuses its associated control.

#### Spacing and Alignment

Provide adequate space between controls and groups of controls. This white space will make it easier for the user to find the information they need.

##### Diretrizes

- As a basic rule of thumb, leave space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant. For example, between icon labels and associated graphics within an icon, 6 pixels are adequate. Between labels and associated components, leave 12 horizontal pixels. For vertical spacing between groups of components, 18 pixels is adequate. A general padding of 12 pixels is recommended between the contents of a dialog window and the window borders.

- Break long lists of choices into smaller groups. For lists of less than about eight items, use radio buttons or check boxes. For longer lists, use a list control or drop-down list.

- Try to keep elements of the same type left-aligned with each other. For instance, in , the group titles (General and Actions) are left-aligned and justified with each other.

- Indent group members 12 pixels to denote hierarchy and association.

- Minimize the number of alignment points in your window. An alignment point is an imaginary vertical or horizontal line through your window that touches the edge of one or more labels or controls in the window.

- Right-justification within groups or the overall window (as indicated by the line labelled "justification" in is pleasing to the eye, but not crucial.

- Lay out components left-to-right, top-to-bottom. Generally, the first element the user is meant to encounter should be in the top-left, and the last in the bottom right. Keep in mind that when localized for non-western locales, interfaces may be reversed so that they read from right to left.

- Using "white" or blank spacing and indentation to delineate groups is cleaner and preferable to using graphical separators such as frames.

- Align controls in your layout exactly. The eye is very sensitive to aligned and unaligned objects. If nothing lines up with anything else in a window, it will be very hard for the user to scan the contents and find the information he wants. Two things that almost line up, but not quite, are equally distracting.

- Be consistent. Use the same spacing, alignment, and component sizes in all dialogs appearing in your application. The OK and Cancel buttons, for example, should all appear exactly 12 vertical and horizontal pixels from the lower right corner of every dialog window.

- Ensure that light and dark areas as well as spacing are equally distributed around the window. Keep in mind that every control or group of controls in your window has a visual "weight," depending on its overall size, color, and how much white space it includes. Darker, larger areas are "heavier," while paler, smaller areas are "lighter."

- Do not design windows that are more than 50% longer in one dimension than in the other. People are more comfortable looking at windows and dialogs whose dimensions stay within the golden ratio (about 1.6 to 1), a ratio that artists and architects have used to create aesthetically-pleasing paintings and buildings for thousands of years.

### Text Labels

To a user with normal vision, textual output provides the majority of the information and feedback in most applications. To a visually-impaired user who may not be able to see or understand any additional graphical output, clear textual output is critical. You must therefore choose and position text carefully on the screen, and leave the choice of fonts and sizes to the user, to ensure that all users are able to use your application effectively.

#### Spacing and Alignment

Use spacing and alignment of text uniformly throughout your application. A basic rule of thumb is to put space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant.

##### Alignment and spacing for different Text elements

Element | Placement | Example
--- | --- | ---
Large Icons (file browser) | Horizontally centered with and (6 pixels, if specification necessary)below large icon | Large icon with text label centered below
Small icons (toolbar) | Vertically centered with and (6 pixels, if specification necessary) to the right of small icons | Small icon with text label to the right
List control label | 6 pixels above and horizontally left aligned with list control or 12 pixels to the left of and horizontally top aligned with list control | List control with text label horizontally aligned above
Radio button and check box labels | 6 pixels to the right of and vertically center aligned with radio button | Radio button with text label to its right
Text field labels | 6 pixels to the left of and vertically center aligned with textfield control | Textbox with text label to its left
Button labels | 12 pixels of padding to either side of centered text (and any accompanying graphic). If appearing in a group of buttons, longest button label sets button size, center all other button labels and accompanying graphics in same-sized buttons | Buttons with centered text
Other component labels (e.g., spin boxes, text fields | 12 pixels between the longest text label and its associated component, all other text labels in component grouping left aligned with the longest label. All labels vertically center aligned with associated components | Drop-down list with label to its left

##### Diretrizes

- If the label precedes the control it is labelling, end the label with a colon. For example, Email: to label a text field into which the user should type their email address. This helps identify it as a control's label rather than an independent item of text. Some assistive technology screen review utilities may also use the presence of a colon to identify text as a control label.

- Ensure that a label with a mnemonic is associated with the control it labels.

- Left-align components and labels, unless all the labels in a group have very different lengths. If they do, right-align the labels instead, to ensure that no controls end up too far away from their corresponding labels.

- Choose label names carefully. Label objects with names that make sense when taken out of context. Users relying on screenreaders or similar assistive technologies will not always be able to immediately understand the relationship between a control and those surrounding it.

- Be consistent with label usage and semantics. For example, if you use the same label in different windows, it will help if it means the same thing in both windows. Equally, don't use labels that are spelled differently but sound the same, e.g., "Read" and "Red", as this could be confusing for users relying on screenreaders.

- Don't use the same label more than once in the same window. This makes life difficult for users relying on tools like magnifiers or screen readers, which cannot always convey surrounding context to the user.

- Do not hard-code font styles and sizes. The user should be able to adjust all sizes and typefaces.

- Do not use more than two or three different fonts and sizes in your application, and choose visually distinct rather than similar-looking fonts in one window. Too many font sizes and styles will make the interface look cluttered and unprofessional, and be harder to read. In general, always use fonts from the current theme, and specify relative rather than absolute sizes.

- Do not use graphical backdrops or "watermarks" behind text, other than those specified by the user's chosen theme. These interfere with the contrast between the text and its background. This can cause difficulty for users with visual impairments, who will therefore normally choose themes that always use plain backdrops.

#### Capitalization

Two styles of capitalization are used in GNOME user interface elements:

Header capitalization

  Capitalize all words in the element, with the following exceptions:

  - Articles: a, an, the.

  - Conjunctions: and, but, for, not, so, yet ...

  - Prepositions of three or fewer letters: at, for, by, in, to ...

Sentence capitalization

  Capitalize the first letter of the first word, and any other words normally capitalized in sentences, such as application names.

The following table indicates the capitalization style to use for each type of user interface element.

##### Capitalization Style Guidelines for User Interface Elements

Element | Style
--- | ---
Check box labels | Sentence
Command button labels | Header
Column heading labels | Header
Desktop background object labels | Header
Dialog messages | Sentence
Drop-down combination box labels | Sentence
Drop-down list box labels | Sentence
Field labels | Sentence
Filenames | Sentence
Graphic equivalent text: for example, Alt text on web pages | Sentence
Group box or frame labels | Header
Items in drop-down combination boxes, drop-down list boxes, and list boxes | Sentence
List box labels | Sentence
Menu items | Header
Menu items in applications | Header
Menu titles in applications | Header
Radio button labels | Sentence
Slider labels | Sentence
Spin box labels | Sentence
Tabbed section titles | Header
Text box labels | Sentence
Titlebar labels | Header
Toolbar button labels | Header
Tooltips | Sentence
Webpage titles and navigational elements | Header

##### Capitalization guidelines for other languages

Languages other than English may have different rules about capitalization. For example, Swedish has no concept of Header capitalization. Contact the GNOME Translation Project if you are in doubt about how to capitalize labels in a particular language.

### Fonts

Only use the fonts that the user has specified in their theme, and in sizes relative to the default size specified in their theme. This will ensure maximum legibility and accessibility for all users.

Do not mix more than two or three font sizes and styles (underlined, bold, italicized) in one window, as this will look unprofessional and distract the user from the information being conveyed.

Provide alternatives to WYSIWYG where applicable. Some users may need to print text in a small font but edit in a larger screen font, for example. Possible alternatives include displaying all text in the same font and size (both of which are chosen by the user); a "wrap-to-window" option that allows you to read all the text in a window without scrolling horizontally; a single column view that shows the window's contents in a single column even if they will be printed in multiple columns; and a text-only view, where graphics are shown as placeholders or text descriptions.

## Icons

Icons are a graphical metaphor presenting a visual image that the user associates with a particular object, state or operation. When a user sees a good icon they are immediately reminded of the item it represents, whether that be an application in the panel menu or the "right aligned" state in a word processor toolbar.

- Icons can assist the user in rapidly scanning a large number of objects to select the desired item. Particularly after a user is accustomed to an icon's appearance, they can identify it more rapidly than a text label.

- Icons can augment text by providing visual suggestions to accompany the descriptive text. Some things are easier to communicate with a picture, even a very small one.

- Icons can compactly represent a large number of objects when there is insufficient space to display textual descriptions (such as in a toolbar).

### Style

GNOME uses a soft, three-dimensional look. This style is achieved by using antialiasing, shading and highlighting techniques. The Gnome Icons tutorial details how one of GNOME's leading artists creates some of these effects.

Components of an icon style can be broken down into several categories such as perspective, dimentionality, lighting effects and palette. These components play an important part in giving a group of icons a collectively distinctive look. For instance, the Java Look and Feel is recognizable by its use of a primary eight-color palette, interior highlighting and diagonal gradients. The Macintosh Aqua style is recognizable by its use of a cool palette based on blue, lighting effects mimicking reflectivity and antialiasing. The GNOME style exhibits a subdued thirty-two color palette, soft drop shadows and a mix between cartoonish and photorealistic graphics.

#### A globe in different icon styles

Java Metal | MacOS/X Aqua | GNOME
--- | --- | ---
Java globe | Aqua globe | GNOME globe

#### Perspective

##### Table perspective

Presents objects as if they were sitting on a table or desk in front of the user.

##### Illustration of the table perspective

illustration of the table perspective

##### Shelf perspective

Presents objects as if they were propped up on a shelf at eye level. Make it look like a police line-up.

##### Illustration of the shelf perspective

illustration of the shelf perspective

#### Lighting

##### Upper left

Design as if there is lighting coming from the upper left corner, with a soft drop-shadow cast within the icon's 48x48 (original design size) borders (120 degrees, 4 pixel distance, 4 pixel blur).

##### Overhead

Design as if there is a light source placed above the "camera", casting a shadow down.

#### Palette

Icons should use colors based on the basic thirty-two color palette, darkening or lightening the colours to achieve the desired look. See

### Kinds of Icons

#### Specifications for different kinds of icons used within GNOME

Icon Type | Sizes (pixels) | Perspective | Light Source | Examples
--- | --- | --- | --- | ---
Object / Document Icons | 24x24, 48x48*, 96x96 | Table | Upper Left | variety of object icons
Application Icons | 24x24, 48x48* | Table | Upper Left | variety of application icons
Toolbar Icons | 24x24*, 48x48 | Shelf | Overhead | variety of toolbar icons
Menu Icons | 16x16 | Shelf | Overhead | variety of menu icons

(* denotes the primary size for this kind of icon)

#### Document Icons

If possible, document icons should convey the type of the file using a physical object. For example a good icon for MPEG video would be a movie reel. Failing the existence of an appropriate object, when a document type corresponds to a specific application, another option is to use a piece of paper with the corresponding application's icon overlayed it as the document icon. This may be appropriate for a document type such as an application's settings files.

- Do not display a piece of paper behind a document icon unless the document type has a use correspondence with physical paper (or a suitable object was not found and you are using the application icon). For example, the final state of most word processing documents is a piece of paper, so it is appropriate to use a piece of paper in the icon. On the other hand, a movie on the computer has little association with a piece of paper, so a piece of paper behind the movie reel primarily introduces visual noise. The use of a piece of paper in most or all document types creates an additional problem: it is harder to scan large numbers of icons because they do not possess distinct outlines. A useful technique for creating a subtle difference between document types with similar roles (for example, between "JPEG", "PNG", "GIF", etc) is to use different colours. Expert users who need to make this distinction frequently will become accustomed to these differences.

- Do not include a file extension in the icon. The document icon's job is not to convey such precise information but to allow for rapid visual distinction between documents. Additionally, this text will not be displayed in the user's preferred font and size. Because many document types are associated with multiple file extensions, a file extension embedded in the icon will also frequently be wrong. In a context where the file extension is actually useful, the application should composite the information onto the icon at runtime (thereby using the correct font and size, as well as getting the extension right).

- Do not customize document icons to a particular Nautilus theme. Document icons are likely to be used in conjunction with a variety of different icon themes, and should work well with all of them.

#### Application Icons

Application's that handle documents should reflect the kind of document they handle in the icon. If an application's predominant purpose is to edit a particular kind of document, it should use this document's icon as its icon.

#### Toolbar Icons

The idea of a toolbar as a shelf filled with tools should be reflected in toolbar icons. Toolbar icons should have the perspective of being viewed head on, as if they were actually sitting on a shelf at eye-level. Some design guides refer to this perspective as "flush".

- Ensure that toolbar icons which will be used together are easy to visually distinguish. Try to make the icons' silhouettes distinct from one another.

- While most user's will view toolbar icons at 24x24 pixels, it is important to include a "large print" set of icons at 48x48 pixels for accesibility reasons.

- Often, you will not have to design any toolbar icons yourself as GTK provides a wide variety of stock icons. You should use these whenever representing one of their intended items. This establishes consistent language across applications, and makes it easier for users to search for items on the toolbar. Do not use stock toolbar icons for anything other than their intended purpose, however, as this will make your application inconsistent with others, and could easily confuse your users.

  To browse the available stock icons, install the development packages for GTK version 2.x and run `gtk-demo`. Double click on Stock Item and Icon Browser to activate the stock icon browser. Note that icons vary in available resolution, so the images presented in the icon browser should not be taken as indicative of the maximum quality of an image. To view the images in PNG format, look in the GTK 2 source code under `gtk/stock-icons`.

#### Menu Icons

Principles of toolbar icon design should be followed with menu icons, just at a smaller size. Where a corresponding toolbar icon exists, a menu icon should mirror its design.

### Designing Effective Icons

#### Rule of Thumb for Icon Metaphors

"If you have to think about an icon to 'get it', the metaphor is too complex"

- #### Design Functionally Suggestive Icons

  Icons should be suggestive of the functionality with which they are associated. The best icon will suggest to the user the primary purpose of the program or operation without having to read accompanying text. Users recognize functionally suggestive icons more rapidly than other forms because they directly associate with a physical object or action.

  #### A functionally suggestive icon for a word processor

  A document with a pencil writing on it

  #### A functionally suggestive icon for underline

  An underlined character

- #### Make Icon Silhouettes Distinct

  It is important to make it easy to visually distinguish icons that will be used together, for example toolbar icons and document icons. The human visual system is excellent at making rapid distinctions between items based on shape, thus a good way to help your users sort through a large number of icons is to use different shapes. You can see the shape of an icon most clearly by turning it into a silhouette: blacken all areas of the icon which are not transparent.

  #### Distinct silhouettes from the GNOME icon theme

  Silhouettes of various toolbar icons

#### Suggested Design Process For Toolbar and Menu Icons

For accessibility reasons, you should create high contrast versions of all icons, in addition to the regular contrast icon. A suggested process for conveniently integrating this into your icon design is as follows:

1. Draw the basic outline as close to 48x48 pixels as possible:

2. Fill in with black and white to create detail. Do not add gratuities such as drop shadows or anti-aliasing:

3. Use the finished image as the large print high contrast icon:

4. GNOME will automatically scale it down to create the 24x24 high contrast icon:

5. Or you may hand-create a 24x24 version, which will be superior in contrast and sharpness:

6. Add color and anti-aliasing to the large print high contrast icon:

7. Add gradients for a smooth, realistic effect:

8. Add a drop shadow (120 degree global angle, 4 pixel distance, 4 pixel blur, 40% opacity), and use the finished image as the large print regular contrast icon:

9. Now you should hand-create a version of this icon at 24x24. Do not simply scale the larger icon, as this icon will be seen by the majority of users and the result of scaling would be less distinct:

10. Create a layer with the large print regular contrast icon's same outline and size then overlay that on the color icon. Give the overlay layer 40% opacity, and use the finished image as the large print low contrast icon:

11. GNOME will automatically scale it down to create the 24x24 low contrast icon:

12. Or you may hand-create a 24x24 version, which will be superior in contrast and sharpness:

#### Problems to Avoid

- ##### Avoid name suggestive icons

  Some icons, such as the original Nautilus file manager icon, do not suggest the program's purpose, but instead suggest the program's name. This is less desirable than a functionally suggestive icon, because an extra layer of abstraction is added (rather than associating file management with an icon representing files, they have to associate file management with nautilus with an image of a nautilus shell). Additionally it makes it difficult for new users who may not know what "Nautilus" is, and hence will not recognize a shell icon as the file manager.

  ##### The original, name suggestive icon for Nautilus

  A picture of a nautilus shell

- ##### Do not include meaningful text in icons

  Icons that contain the text of the program name in the icon. They effectively contain no metaphor or picture for the user to identify with, and are probably harder to read than the accompanying caption. Since icons draw the eyes, an icon that is harder to identify than text is potentially worse than no icon at all. Hence "text icons" should not be used. Moreover, text should be avoided in icons because it makes the icons difficult to translate. If there is text in icons it should not form words in your native language, a good metric for ensuring that the particular text is not lending to the meaning of the icon.

  ##### Text in the original GEdit icon

  The original GEdit icon, a rectangle containing the word "GEdit".

- ##### Do not rely on information your users will not have

  Random icons appear to have no association with the application (except perhaps some odd connection in the mind of the developer). These icons should never be used and will likely serve to confuse the user more than help them. The icon's purpose should not be to "look pretty"; this is merely a very desirable side effect.

  The SodiPodi project logo is a squirrel, which is used as the application icon. However, because the logo has no obvious connection to a user, it is a poor icon. Make sure that you are not relying on information that users won't necessarily possess.

  ##### A seemingly random icon for SodiPodi

  A squirrel

- ##### Do not include extraneous information

  Remember that icons will often be viewed in a smaller form. Too much information may render the icon unintelligible when it is shrunk in size (e.g. to be placed on a panel, or in the tasklist). Too much information also makes it easier for users confuse the purpose of the application. For example, in user testing many users thought an older version of the Evolution icon (below) would launch a word processor. They were misled by the pencil and the paper, which could be seen as extraneous information: it is implicit that the mail program will allow you to write messages as well as receive them. A better icon might have been a simple envelope. Foremost in the icon designer's mind should be a consideration of the minimal visual elements necessary to express the purpose of the program.

  ##### Extraneous information - the Evolution icon

  The Evolution icon

  This Gnumeric icon (below) is a great icon except for the introduction of extra visual noise. The extra sheet of paper with the 'g' on it behind the spreadsheet and chart adds no significant value to the icon and provides extra visual distraction. In this case the contribution of the extraneous element to the appearance of the icon is negative. Simple, well-balanced icons look more attractive than cluttered icons. An improved icon might contain only the spreadsheet and chart; larger because they can use all of the space in the icon, and hence more visually distinct.

  ##### Extraneous information - the old Gnumeric icon

  The Gnumeric icon

- ##### Do not include body parts in the icon

  Because GNOME aims to be an international desktop, it needs to avoid imagery that is potentially offensive or crass to other cultures. A prime source of offensive imagery is various body parts in a number of different configurations. Aside from offensive gestures with the hands, arms or fingers; body parts that are considered "clean" in one culture (such as eyes), will be considered tasteless or gross to another (such as a nose). Based on a survey of icons in GNOME, body parts frequently appear in the least communicative icons (often "pointing" at some element in the icon); they are being used as an ineffective crutch for poor metaphor. In these situations body parts should not be used. Even in situations where the metaphor is appropriate (for example an eye representing the sawfish appearance capplet) it is better to avoid using a body part. Often body parts have been used in GNOME to suggest a human "choosing" or "using" something. This is normally an unnecessary point for the icon designer to make. People naturally attempt to understand objects in reference to themselves (show someone a bat and they will think of hitting something with the bat, show someone a tool and they will think of using it, etc). For example, the font selector shows a finger pointing to an "F" suggesting the user choosing between a series of fonts. A better icon would be the text "Aa" presented in an ornate font (calling attention to the font rather than the text). The user doesn't need to be told that they are "choosing" the font, they can infer that easily.

  ##### Using body parts - the font selector icon

  The original Font Selector Icon

  ##### A better icon for the Font Selector

  A simple replacement icon showing an ornate "Aa"

- ##### Do not base icons off word puns

  This should be avoided for a couple reasons, the most obvious of which is that puns do not translate well. For example, representing the "system log monitor" as a log will likely be uncommunicative in languages other than English. Additionally, most users do not comprehend the word play until it is too late for the icon to assist them. Even after being familiar with the "system log monitor" being represented as a log, users do not form the association fast enough for the icon to assist through in scanning through menu entries. A popular instance of this problem was the proliferation of icons representing the "World Wide Web" as a spider web in the mid 1990s. Part of the value of icons is that they bypass linguistic comprehension and hence are complementary to captions, allowing users to utilize more areas of the mind than linguistic recognition (already used in scanning for captions) when they hunt for items.

  ##### Word play - System Log Monitor icon

  A tree log

- ##### Do not employ violent imagery

  Just as words like "kill" and "slay" are inappropriate in interfaces, violent or destructive icons should be avoided. The "shut down" icon uses the image of an explosive detonation switch, presumably trying to convey the idea of ending something abruptly. However, this icon is likely to intimidate some users of the computer who will not want to click on the icon for fear of breaking something.

  ##### Destructive-looking Shutdown icon

  An explosive detonation button

### Designing Accessible Icons

The GNOME desktop includes a high contrast theme that make the desktop and the applications running on it accessible to users with a range of visual impairments.To be considered fully accessible, all icons in your application must be replaced by a suitable alternative when this themes is used.

#### Low Contrast Icons

Low contrast icon themes were deprecated in GNOME 2.22. It is no longer necessary to deliver low contrast icon equivalents.

#### High Contrast Icons

High contrast icons are greatly simplified versions of an application's existing regular icons. They are drawn with two colors, black and white, and thicker borders. This style allows high contrast icons to be distinguishable when viewed by a user with a visual impairment. Below is an approximation of what well-designed high contrast icons look like when viewed by someone with a visual impairment.

##### Simulation of low vision user viewing high contrast icons

Description | High Contrast Icon | Simulated Appearance
--- | --- | ---
Book | Book icon | Blurred Book icon
CD-ROM | CD-ROM icon | Blurred CD-ROM icon
Copy | Copy icon | Blurred Copy icon

If a regular icon uses a simple, straightforward metaphor the corresponding high contrast icon can often use the same metaphor. In many cases the same metaphor will need to be drawn differently to create a simplified high contrast icon.

##### Simplified representation of metaphors for high contrast icons

Comparison of photorealistic style of regular icons with the simpler, line-art style of high contrast icons

High contrast icons are created in a vector drawing program. Black and white shapes are layered to create a simplified icon. The process feels like layering black and white pieces of construction paper, as if you were assembling a collage.

##### Layered technique for high contrast icons

Exploded view of layers used in high contrast floppy disk icon

##### Reuse existing shapes

Often shapes from existing high contrast icons can be resized and reused to more quickly build up a new icon.

##### Don't forget the border!

It is useful to design high contrast icons over a temporary background color so you don't forget to draw the external white border.

#### Low Contrast Icons

##### Low Contrast Icons

Low contrast icon themes were deprecated in GNOME 2.22. It is no longer necessary to deliver low contrast icon equivalents.

The goal of low contrast themes is to eliminate, as much as possible, light values (e.g. a large 'V' value in HSV). To achieve this, the colors in low contrast icons are compressed toward the middle value range, i.e. dark colors are lightened and light colors are darkened.

Low contrast icons are generated from the existing regular icons by adjusting the levels in GIMP. The Input Levels are set to 100, 1.25, 200 and the Output Levels are set to 100, 160, as shown in the Levels dialog below. Large numbers of regular icons can be quickly converted to low contrast by using GIMP's scripting facilities.

##### Levels dialog in GIMP showing correct levels for generating low contrast icons

Levels dialog in GIMP showing input levels set to 100, 1.25, 200, and output levels set to 100 and 160.

## User Input

### Mouse Interaction

#### Buttons

##### A plethora of pointing devices: mouse, trackball, foot-operated mouse, joystick, trackpad, and a finger-mounted pointing device.

Pictures of different types of pointing device, including mouse, trackball, foot-operated mouse and joystick.

For most users, the mouse provides the main way of interacting with graphical user interfaces. The term "mouse" is used in this chapter to include other pointing devices that can be used to move the pointer around the screen, such as trackballs, trackpads, spaceballs, graphics tablets, or assistive technology devices that emulate a mouse.

For right-handed users, the left button on a conventional mouse is used for the majority of mouse actions. We therefore call it the left button here, even though that may not physically be the case. For this reason, you may sometimes see this button referred to in code or documentation as "Button 1" or the "Selection Button".

Similarly for right-handed users, the right button on a conventional mouse is used for operations involving pop-up menus. We therefore call it the right button in this chapter. You may sometimes see this button referred to in code or documentation as "Button 3" or the "Menu Button".

A conventional mouse with three buttons normally has its third button (or a scrollwheel that acts as a button when pushed) between the left and right buttons. We therefore call it the middle button, but you may sometimes see this referred to in code or documentation as "Button 2" or the "Transfer Button".

##### Diretrizes

- Your application uses left button gestures for selecting, activating components, dragging, and the display of drop-down menus.

- Your application uses right button gestures to display and select actions from a popup menu.

- Your application uses the middle button to paste the current PRIMARY (usually the last-highlighted) selection at the pointer position, as follows:

  ##### Effect of modifier keys on a middle button transfer operation

  Modifier | Function
  --- | ---
  Unmodified | Copy selection
  Ctrl | Copy selection
  Shift | Move selection
  Shift Ctrl | Create link, shortcut or alias to selection

  Do not over-ride this functionality in any part of your user interface where the transfer action is likely to be useful. If you do intend to use the middle button for a different purpose somewhere, only do so as a shortcut for experienced users, and only for operations that can also be performed without using the right button or middle button.

- If present on the mouse, the scrollwheel should scroll the window or control under the pointer, if it supports scrolling. Initiating scrolling in this way should not move keyboard focus to the window or control being scrolled.

- Ctrl scrollwheel-up should zoom into the window or control under the mouse pointer, and Ctrl scrollwheel-down should zoom out. Zooming in this way should not move keyboard focus to the window or control being zoomed.

- Do not depend on input from the middle or right mouse buttons. As well as being physically more difficult to click, some pointing devices and many assistive technology devices only support or emulate the left mouse button. Some assistive technologies may not even emulate the mouse at all, but generate keyboard events instead.

- Ensure that every operation in your application that can be done with the mouse can also be done with the keyboard. The only exceptions to this are actions where fine motor control is an essential part of the task. For example, controlling movement in some types of action games, or freehand painting in an image-editing application.

- Do not warp the mouse pointer, or restrict mouse movement to part of the screen. This can interfere with assistive technologies, and is usually confusing even for users who do not rely on assistive technologies.

- Do not require the use of chording (pressing multiple mouse buttons simultaneously) for any operations.

- Do not require the use of multiple (triple- or quadruple-) clicking actions for any operations, unless you also provide an accessible alternative method of performing the same action.

- Allow all mouse operations to be cancelled before their completion. Pressing the Esc key should cancel any mouse operation in progress, such as dragging and dropping a file in a file manager, or drawing a shape in a drawing application.

- Do not assign any actions exclusively to the middle button of a three-button mouse, as not all mice have one.

- Do not hard-code mouse target sizes, or make them too small. Define any mouse targets to be at least as large as the arrow button in a GtkSpinBox in the current gtk theme. Bear in mind that a user with impaired dexterity or vision may be using a theme that results in considerably larger widgets than the default theme.

- Do not refer to particular mouse buttons in your interface unless absolutely necessary. Not everybody will be using a conventional mouse with left, middle and right buttons, so any text or diagrams that refer to those may be confusing.

#### Selecting Objects

##### Mouse and keyboard equivalents

For controls or windows that contain a number of objects that the user can select, either singly or multiply, ensure the following mechanisms are in place to allow selections to be made using either the mouse or the keyboard.

###### Standard mouse and keyboard selection mechanisms

| Mouse | Keyboard
--- | --- | ---
Select item, deselect all others | Click | Space
Add/remove item from selection | Ctrl click (toggles item's selected state) | Ctrl Space (toggles focused item's selected state)
Extend selection | Shift click | Shift Space, Shift Home, Shift End, Shift PageUp, or Shift PageDown
Move focus | Click appropriate item to select it | Cursor keys, Home, End, PageUp, and PageDown move focus and selection simultaneously. Ctrl cursor keys, Ctrl Home,Ctrl End, Ctrl PageUp, and Ctrl PageDown move focus without affecting current selection.
Select All | Click first item, then Shift click last item | Ctrl A
Deselect All | Click container background | Shift Ctrl A
Activate selection | Double-click to activate a single selection. Shift or Ctrl double-clicking extends or adds item to selection first before activating the entire selection. | Return activates entire selection. If nothing is currently selected, selects currently-focused item first.
Invert Selection | No mouse equivalent | Ctrl I

##### Bounding Box Selection

For a container whose objects may be arranged in two dimensions, for example the icon view in a file manager, allow multiple selection by dragging a bounding box (sometimes called a "rubber band") around one or more objects. Shift left button drag should add all the objects within the bounding box to the existing selection. Ctrl left button drag should toggle the selected state of all the objects within the bounding box.

###### Diretrizes

- Allow a bounding box selection to begin only if the initial mouse button press is made:

  - Within the bounds of the container's background, and

  - outside the bounds of any another object in the same container that can be dragged.

  In a drawing application, for example, this means that a bounding box click and drag could start on a blank area of the canvas, or within a shape that had been locked down to prevent accidental editing, but not in an active shape which would itself be dragged instead.

- Select any objects that lie wholly or partly within the bounding box when the mouse button is released.

- Use dynamic highlighting during the drag to show which objects will be selected. Do not wait until the mouse button is released. This avoids any uncertainty about which objects will be selected by the bounding box.

- When a bounding box is being dragged out within a scrollable window, support automatic scrolling of that window when the box is dragged near the window's edges.

###### Examples illustrating dynamic selection highlighting during bounding box selection. In the first example, the folder color and label highlighting changes to indicate selection. In the second, selection is indicated by the addition of resizing handles to selected objects.

Example illustrating dynamic selection highlighting during bounding box selection
Example illustrating dynamic selection highlighting during bounding box selection

#### Drag and Drop

Drag and drop is a direct manipulation technique, where you perform actions on selected objects by moving them around the screen with the mouse. You "drag" an object by clicking it, then holding the button while you move the pointer to the object's target location. The object is "dropped" at that location by releasing the mouse button.

##### Diretrizes

- Use drag and drop only where the user can reasonably guess what the effect might be. The most common uses are:

  - to move or copy objects from one place to another

  - to link one object to another

  - to perform an action on the objects by dropping them onto an icon representing that action, such as a trash can or printer icon.

- Provide visual feedback throughout a drag and drop operation. Highlight valid targets and change the mouse pointer as it passes over them. Use the "no drop" mouse pointer when passing over invalid drop targets. See also .

- Augment the mouse pointer with a representation of the objects being dragged. Keep this representation small or make it translucent, so as not to obscure possible drop targets underneath it. See also .

  ##### Example of copy pointer augmented by an icon representing the file being copied

  Copy pointer superimposed on icon representing a file being copied, to form a "copy file" pointer

- Only allow objects to be copied between applications, not moved. This avoids any confusion about which application's Undo function reverses the operation.

- Allow the user to cancel a drag and drop operation by all of these methods:

  - pressing Esc before releasing the mouse button

  - dropping the object back on its original location

  - performing a query drag and selecting Cancel on the pop-up menu (see )

  - dropping the object on an invalid drop target.

- Allow the user to undo the effects a drag and drop operation by selecting Edit Undo.

- Allow multiple objects to be dragged by Shift or Ctrl selecting them, then dragging any one of the selected objects.

- Ensure that keyboard users can replicate all drag and drop actions using only menu items or keyboard shortcuts, such as Copy (Ctrl C) and Paste (Ctrl V).

- When an item is being dragged within or into a scrollable window, support automatic scrolling of that window when the mouse is moved near its edges.

- Pop up a menu when the user attemps to drop multiple objects on a target that only accepts single objects. On the menu, list all the objects being dragged, and a Cancel item.

##### Overriding drag and drop behavior

###### Keyboard Modifiers

Allow the user to force the behavior of a drag and drop operation by holding the Ctrl, Shift or both keys throughout. If the user changes modifier keys after they have started the drag, change the mouse pointer immediately and perform the new action when the mouse button is released.

###### Effect of modifier keys during a drag and drop operation

Modifier | Function
--- | ---
Ctrl | Copy
Shift | Move
Shift Ctrl | Create link, shortcut or alias

###### Query Drag

Allow the user to drag objects with the middle button , or with Alt left button. Pop up a menu when the mouse button is released, offering the choice of Copy, Move and Link (or whichever subset of those actions is available), and Cancel. Dragging in this way is known as query drag because it prompts the user before changing anything.

##### Mouse Pointers to Use for Drag and Drop

Use the default GTK drag and drop pointers for the standard transfer operations listed below. This consistency helps ensure the user will know exactly what to expect when they release the mouse button. If you have to design a pointer for a non-standard transfer action not listed here, follow the style of the standard pointers.

###### Mouse Pointers for Drag and Drop

Pointer Shape | Meaning
--- | ---
"Move" pointer | Move selection. The dragged selection will be moved to the drop location, removing it from its previous location.
"Copy" pointer | Copy selection. The dragged selection will be copied to the drop location, leaving the original intact.
"Link" pointer | Link selection. A link to the selection will be inserted at the drop location. How the link appears will be application-dependent, it may be a hyperlink, an icon, or a duplicate of the original selection, for example.
"Query drop" pointer | Middle button or Alt-left button drag. A pop-up menu will be posted at the drop location to ask whether the user wants to Move, Copy, or Link the selection, or Cancel the operation.
"Can't drop here" pointer | Can't drop here. Show this pointer while the mouse is over an area where the selection cannot be dropped.

#### Mouse Interaction with Panel Applications (Applets)

All objects on the desktop must behave consistently. Despite their specialized nature, applets are no exception.

##### Diretrizes

- The unmodified left mouse button must be sufficient to operate all your applet's controls. Applets are meant to be simple enough that modified clicking, or clicking with other mouse buttons (except to pop up the applet's menu) is never required.

- Clicking the right button anywhere within the applet's enclosing window must display either the popup menu for the whole applet, or the popup menu for the control under the mouse pointer. Do not have "dead areas" in your applet that do not respond to a right click.

- Do not use the middle button for anything except dragging the applet to a new location. Middle-clicking and dragging anywhere within the applet window must move the applet, do not require a drag bar or similar device.

  Ctrl left button drag should copy the applet, if moving to another panel; unmodified drag or Shift left button drag should move the applet, if moving to another panel. If moving within same panel, Ctrl=switched movement, Shift=push movement, Alt=free movement.

### Keyboard Interaction

#### Keyboard Navigation

A well-designed keyboard user interface plays a key role when you are designing applications. Many power-users prefer to perform most operations with the keyboard rather than the mouse. Visually-impaired users can navigate software more effectively using the keyboard, because using the mouse depends on visual feedback of the mouse pointer location. And mobility impairments can prevent a user from successfully navigating using the mouse, because of the fine motor control skills required.

Make all mouse actions available from the keyboard, and include keyboard access to all toolbars, menus, links and buttons. Every function your application provides must be available using the keyboard alone. Hiding your mouse while you test your application is a great way to test this!

##### Dialog and menu, with some of their access and shortcut keys indicated

Screenshot of a dialog and a menu with some of their access keys and shortcut keys highlighted

Most functionality is easy to make available from the keyboard, by using access keys and shortcut keys, and the toolkit's built-in keyboard navigation features. All controls with labels should have access keys, and frequently-used menu items should be assigned shortcut keys. However, operations that rely on drag-and-drop, for example, may require more thought to make them keyboard accessible.

##### Diretrizes

- Provide efficient keyboard access to all application features. In particular, ensure every control on menus and in dialogs are directly focusable using access keys or shortcut keys.

- Use a logical keyboard navigation order. When navigating around a window with the Tab key, keyboard focus should move between controls in a predictable order. In Western locales, this is normally left to right and top to bottom.

- Ensure correct tab order for controls whose enabled state is dependent on check box, radio button or toggle button state. When such a button is selected, all its dependent controls should be enabled, and all the dependent controls of any other button in the group should be disabled. When the user selects a check box, radio button or toggle button that has dependent controls, do not automatically give focus to the first dependent control, but instead leave the focus on the button.

- Do not over-ride existing system-level accessibility features. For example, the MouseKeys feature in the GNOME Keyboard Accessibility preferences dialog allows mouse movement and button clicks to be simulated using the keypad. Therefore you cannot add features to your application that can only be accessed by pressing keys on the keypad, as users relying on the MouseKeys feature will not be able to use them.

- Ensure that any text that can be selected with the mouse can also be selected with the keyboard. This is a convenience for all users, but especially for those for whom fine control of the mouse is difficult.

- Ensure that objects that can be resized or moved by drag and drop can also be resized or moved with the keyboard. For example, icons and windows on the desktop. Where precision sizing and placement is potentially important, e.g. shapes in a diagram, also consider providing a dialog into which you can type co-ordinates, or a means of snapping objects to a user-definable grid.

- Do not use general navigation functions to trigger operations. For example, do not use basic Tab keyboard navigation in a dialog to activate any actions associated with a control.

- Show keyboard-invoked menus, windows and tooltips near the object they relate to, but without hiding or obscuring the object to which the menu or tooltip refers,. In GNOME, popup menus are activated with Shift F10, and tooltips with Ctrl F1.

- Provide more than one method to perform keyboard tasks where possible. Users may find some keys and key combinations easier to use than others.

- Do not assign awkward reaches to frequently performed keyboard operations. Some people may only be able to use one hand on the keyboard, so shortcuts that can be easily used with one hand are preferable for common operations. In any case, having to frequently perform long or difficult reaches on the keyboard can increase muscle strain for all users, increasing the risk of pain or injury.

- Do not require repetitive use of simultaneous keypresses. Some users are only able to press and hold one key at a time. Assistive technologies such as the GNOME Keyboard Accessibility preferences dialog do allow users to press the keys sequentially rather than simultaneously, but this of course means the operation will take longer for them.

#### Choosing Access Keys

Give all labelled components an access key (underlined letter), with the exception of toolbar controls which would use up too many access key combinations.

Choose access keys to be as easy to remember as possible. Normally, this means using the first letter of the label. However, in complex windows, the choice can become more difficult. Here are some simple rules:

1. Assign access keys to the most frequently-used controls first. If it's not clear which controls will be the most frequently used, assign access keys from left to right, top to bottom (for Western locales).

2. Use the first letter of the label, or of one of its other words if it has more than one. If another letter provides a better association (e.g. "x" in Extra Large) however, consider using that letter instead.

3. If the first letter is not available, choose an easy to remember consonant from the label, for example, "p" in Replace.

4. If no such consonants are available, choose any available vowel from the label.

If duplication of access keys in a window is unavoidable, you should still refrain from duplicating the access keys for any of these buttons that appear in the same window: OK, Cancel, Close, Apply or Help.

Also, it is better not to assign access keys to "thin" letters (such as lowercase i or l), or letters with descenders (such as lowercase g or y) unless it is unavoidable. The underline does not show up very well on those characters in some fonts.

Applications using a non-Roman writing system in conjunction with a standard keyboard can have control labels prefixed with Roman characters as access keys.

#### Choosing Shortcut Keys

The tables in summarize the standard shortcut keys to use when your application supports those functions. Your application will not necessarily support all of these functions, see for more information. However, use the recommended shortcut keys for those functions you do support.

You will probably want to add your own shortcut keys for functions specific to your application. If so, as well as following the guidelines below, look at any other existing similar applications to see which shortcut keys they have defined. Your users may already be using those or similar applications, so being consistent where it is possible and sensible to do so will provide a better user experience for them when they begin to use yours.

##### Diretrizes

- Use Ctrl letter in preference to other combinations when choosing new shortcut keys.

- Insert, Delete, Home, End, Page Up and Page Down are acceptable shortcut keys for functions that are closely related to those keys' normal system-defined uses. Do not assign them to unrelated functions just because you've run out of other shortcut key combinations, however.

- Only assign shortcut keys to the most commonly-used actions in your application. Do not try to assign a shortcut key to everything.

- Choose new shortcut keys to be as mnemonic as possible, as these will be easier to learn and remember. For example, Ctrl E would be a good shortcut for a menu item called Edit Page.

- Use Shift Ctrl letter for functions that reverse or extend another function. For example, Ctrl Z and Shift Ctrl Z for Undo and Redo.

  ##### Unicode entry shortcuts

  Note that you cannot use Shift Ctrl A-thru-F or Shift Ctrl 0-thru-9 for your own purposes, as these combinations are used to enter unicode characters in text fields.

- Do not use Ctrl number or numbered function keys as shortcut keys, unless the number has some obvious relevance to the action. For example, Ctrl 2 and Ctrl 3 may be acceptable shortcut keys for View 2D View and View 3D View in a 3D modelling application.

- Do not use Alt key combinations for shortcut keys, as these may conflict with window manager or menu access keys.

- Do not use symbols that require Shift or other modifiers as part of a shortcut, for example Ctrl%. Remember that symbols that can be accessed without a modifier key on your keyboard may be more difficult to access on different international keyboards.

- Do not assign shortcut keys to menu items that change over time, for example a list of open windows on the Window menu, or a recently-used file list on the File menu. Do assign access keys to these items, however.

- Do not use any of the standard shortcut keys listed in for your own purposes, even if your application doesn't support those functions. This helps reinforce consistency between all GNOME applications.

#### Standard Application Shortcut Keys

If your application uses any of the standard functions listed in the following tables, use the recommended standard keyboard shortcut for that function.

##### Standard GNOME application shortcut keys and access keys - File menu

Function | Shortcut | Description
--- | --- | ---
New | Ctrl N | Create a new document
Open | Ctrl O | Open a document
Save | Ctrl S | Save the current document
Print | Ctrl P | Print the current document
Close | Ctrl W | Close the current document
Quit | Ctrl Q | Quit the application

##### Standard GNOME application shortcut keys and access keys - Edit menu

Function | Shortcut | Description
--- | --- | ---
Undo | Ctrl Z | Undo the last operation
Redo | Shift Ctrl Z | Redo the last operation
Cut | Ctrl X | Cut the selected area and store it in the clipboard
Copy | Ctrl C | Copy the selected area into the clipboard
Paste | Ctrl V | Paste contents of clipboard at mouse/cursor position
Duplicate | Ctrl U | Duplicate the currently-selected items and add them to the same window, without affecting the clipboard
Select All | Ctrl A | Select everything in focused control or window
Invert Selection | Ctrl I | Select everything in focused control or window that was previously unselected, and deselect everything that was previously selected
Delete | Del | Delete selection
Find... | Ctrl F | Find matches in the current document, highlighting them in-place
Search... | Ctrl F (see note below) | Search for matches in multiple documents, files or other external sources
Find Next | Ctrl G | Find the next match
Replace... | Ctrl H | Find and replace matches
Rename | F2 | Switch the selected item's label into edit mode, allowing user to type in a new name.

##### Find and Search

If your application requires both Edit Find and Edit Search menu items, use Shift Ctrl F as the shortcut for Search.

##### Standard GNOME application shortcut keys and access keys - View menu

Function | Shortcut | Description
--- | --- | ---
Zoom In | Ctrl Plus | Zoom in on the document
Zoom Out | Ctrl Minus | Zoom out of the document
Normal Size | Ctrl 0 | Restore to zoom level to normal size (generally 100%)
Refresh | Ctrl R | Redraw current view of document, without checking if content has changed
Reload | Ctrl R (see note below) | Reload the current document, updating content from source if necessary
Properties | Alt Enter | Display the selected object's Properties window. May alternatively appear on the File menu if the document itself is the only object in the application whose properties can be inspected.

##### Reload and Refresh

If your application requires both View Reload and View Refresh menu items, use Shift Ctrl R as the shortcut for Reload.

##### Standard GNOME application shortcut keys and access keys - Bookmarks menu

Function | Shortcut | Description
--- | --- | ---
Add Bookmark | Ctrl D | Add a bookmark for the current location
Edit Bookmarks... | Ctrl B (see note below) | Open a window in which the user can edit and organise saved bookmarks

##### Bold and Edit Bookmarks

If your application requires both Format Bold and Bookmarks Edit Bookmarks... menu items, use Shift Ctrl D as the shortcut for Edit Bookmarks.

##### Standard GNOME application shortcut keys and access keys - Go menu

Function | Shortcut | Description
--- | --- | ---
Back | Alt Left | Go to the previous location in the navigation chain
Next | Alt Right | Go to the next location in the navigation chain
Up | Alt Up | Go up one level in the navigation hierarchy
Home | Alt Home | Go to the starting page defined by the user or application
Location... | Ctrl L | Present or focus an entry field into which the user can type a new address or location to view

##### Standard GNOME application shortcut keys and access keys - Format menu

Function | Shortcut | Description
--- | --- | ---
Bold | Ctrl B | Make selected text bold/regular
Underline | Ctrl U | Underline/remove underline from selected text
Italic | Ctrl I | Make selected text italic/regular

##### Standard GNOME application shortcut keys and access keys - Help menu

Function | Shortcut | Description
--- | --- | ---
Contents | F1 | Show help contents page for the current application

##### Standard Window Manager Shortcut Keys

The following shortcut keys are used by many window managers, and should not normally be over-ridden by your application.

###### Standard window manager shortcut keys and access keys

Function | Shortcut | Description
--- | --- | ---
Switch primary windows | Alt Tab, Shift Alt Tab | Switch focus to the next or previous top level window on the desktop
Switch panels | Ctrl Alt Tab, Shift Ctrl Alt Tab | Switch focus to the next or previous panel on the desktop
Log out | Ctrl Alt Del | Open the session logout confirmation dialog
Window menu | Alt Space | Open the window menu
Close | Alt F4 | Close the focused window
Restore | Alt F5 | Restore the focused to its previous size
Switch secondary windows | Alt F6, Shift Alt F6 | Switch focus to the next or previous secondary window associated with the application ( )
Move | Alt F7 | Move the focused window
Resize | Alt F8 | Resize the focused window
Minimize | Alt F9 | Minimze the focused window
Maximize | Alt F10 | Maximize the focused window
Full Screen | Ctrl F11 | Show the window in full screen mode, with no border, menubar, toolbar or statusbar

##### Standard Widget Navigation Shortcut Keys

The following shortcut keys are reserved for keyboard navigation use by the various widgets used in GNOME, and should not normally be over-ridden by your application.

###### Standard GNOME keyboard navigation keys for widgets

Chave | Function
--- | ---
Tab, Shift Tab | Moves keyboard focus to next/previous control
Ctrl Tab, Shift Ctrl Tab | Moves keyboard focus out of enclosing widget to next/previous control, in those situations where Tab alone has another function (e.g. GtkTextView)
Ctrl F1 | Pop up tooltip for currently-focused control
Shift F1 | Show context-sensitive help for currently-focused window or control
F6, Shift F6 | Give focus to next/previous pane in a GtkPaned window
F8 | Give focus to splitter bar in paned window
F10 | Give focus to window's menu bar
Shift F10 | Pop up contextual menu for currently-selected objects
Space | Toggle selected state of focused check box, radio button, or toggle button
Return | Activate focused button, menu item etc.
Home, End | Select/move to first item in selected widget
PageUp, Ctrl PageUp, PageDown, Ctrl PageDown | Scroll selected view by one page up/left/down/right

##### Additional Widget Navigation Shortcut Keys

The following emacs-style navigation shortcut keys are still available in GNOME 2.0 text entry fields (by selecting the "emacs" scheme in the GNOME Keyboard Shortcuts preferences dialog), but are disabled by default. Since some users will still want to use them, do not over-ride them for your own purposes in any situations where a text entry control has focus.

###### Emacs-style navigation keys for widgets

Chave | Function
--- | ---
Ctrl A | Move cursor to beginning of line
Ctrl D | Delete character following/under cursor
Ctrl E | Move cursor to end of line
Ctrl K | Delete from cursor to end of line
Ctrl U | Delete current line
Ctrl W | Cut to clipboard
Ctrl Y | Paste from clipboard
Ctrl Space | Set mark
Ctrl Del, Alt D | Delete from cursor to end of word
Ctrl Backspace | Delete from cursor to start of word
Alt Space | Delete all whitespace around cursor, reinsert single space
Alt\ | Delete all whitespace around cursor

#### Keyboard Interaction with Panel Applications (Applets)

Panels have been fully keyboard navigable since GNOME 2.0. Since your panel application can gain keyboard focus, you must ensure that it is also keyboard navigable.

The rules for panel application keyboard navigation are mostly the same as those for any other window. However, there is one imporant difference:

- Do not use the Tab key as the means of moving focus between controls in a panel application. Use the arrow keys for this purpose instead.

When an object on a panel has focus, the Tab key normally moves focus to the next object on the panel. If your panel application also used Tab for its own internal navigation, the user would have to press Ctrl Tab to move focus out of your panel application instead. This inconsistency would be detrimental to the user experience.

## Language

Consistent labelling creates a familiar environment that the user can navigate comfortably. The more familiar the environment, the easier task of finding information.

### Labels

#### Controls

Clear, consistent and concise labelling of controls helps users to work out the purpose of a window or dialog they have never seen before. To a visually-impaired user, clear labels are even more important. A user who relies on a screenreader has no assistance from icons, layout, or spacing to work out what the controls do, so clear labelling is essential.

##### Diretrizes

- Keep labels short. This:

  - Reduces the expansion of text when translated, and thus minimizes the effort required to localize the UI. Translated English text can expand up to 30% in some languages.

  - Facilitates the use of translation engines.

  - Improves speed of comprehension for the user.

  Do not shorten your labels to the point of losing meaning, however. A three-word label that provides clear information is better than a one-word label that is ambiguous or vague. Try to find the fewest possible words to satisfactorily convey the meaning of your label.

- Do not include text in windows that describes how to use the interface, for example You can install a new theme by dropping it here. As well as adding visual clutter, descriptive labels can also conflict with information provided in documentation.

- Use standard terms. You can find a list of standard user interface terms in the GNOME Documentation Style Guide, Recommended Terminology.

- Apply standard capitalization rules. See for guidelines about capitalization of user interface labels

#### Tooltips

##### Toolbar Tooltips

A toolbar tooltip is the short description of a toolbar control's functionality that the user sees when they mouse over it.

###### Diretrizes

- Concisely state the purpose of the control. The tooltip should be more descriptive than the corresponding menu item name, if there is one, but not verbose. For example, Undo last action for the Undo button.

- Use sentence capitalization rules. See .

##### Application Tooltips

An application tooltip is the short description of your application that the user sees when they mouse over the launcher or menu item for your application. It is stored in the comment field of your application's `desktop` file. See

###### Diretrizes

- Create short tooltips. Aim to accurately communicate the functionality of an element with the fewest words possible.

- Use sentence capitalization rules. See .

- Use standard punctuation rules, with the exception that you do not use a period to end the tooltip.

#### Menus

##### Diretrizes

- Use the recommended standard labels for menu items and titles, where they exist. Do not use synonyms such as Exit instead of Quit. See for a list and descriptions of standard menu items and titles.

- Use header capitalization rules for all menu items and titles. See for more information.

### Warning and Error Messages

A good warning or error message contains two elements:

1. A brief description of the problem.

2. A list of ways the user can remedy the problem.

Both of these elements should be presented in non-technical, jargon-free language, unless your target audience is particularly technically-minded.

If your application knows enough about the problem to be able to give all this information to the user, it will often be capable of rectifying the problem itself when the user has decided which course of action they want to take. For example, if the problem is insufficient memory, tell the user which currently-running application is taking up the most memory, and provide a button to close it for them. (Do not offer to launch a graphical process manager, however, which is something most users should never see!)

See for more detailed information on writing and presenting errors, warnings and information alerts.

### Online Help

Writing online help is a specialized task, and is therefore not covered in any depth here. Refer to the GNOME Documentation Styleguide for guidance on writing clear, consistent and helpful documentation for your application.

## Checklists

### Things You Can Do Yourself

#### Before You Start

Write down the type of people you expect to use your application. Then write some "scenarios" for each type of user— a little story that describes the typical tasks those users will use your application for. These tasks should be along the lines of:

> Fred needs to find an email about widgets that he received last week

rather than

> Fred clicks on the Find button and types `widgets` into the dialog.

This way, you can use the same scenarios to test and compare different interface designs, and to spot any missing functionality.

Include these user descriptions and scenarios with the documentation you commit to CVS. This way, other contributors will get to understand your users too, can help to develop the application with that knowledge, and can provide more scenarios of their own.

#### Keyboard Access and Focus

When you have started implementing your interface, hide your mouse, and make sure you can still use it to do everything using only the keyboard. Implement keyboard functionality at the same time as mouse functionality— don't leave it until the end.

Using only keyboard commands, move the focus through all menu bars and toolbars in the application. Also confirm that:

- Context sensitive menus display correctly (Shift F10).

- Tooltips can be popped up and down for all controls that have them (Ctrl F1, Esc).

- All functions listed on the toolbar can be performed using the keyboard.

- You can fully operate every control in the client area of the application and dialogs.

- Text and objects within the client area can be selected.

- Any keyboard enhancements or shortcut keys are working as designed.

- Verify that when moving among objects, the visual focus indicator is easy to identify at all times.

#### Theming, Colors and Contrast

Test various GNOME themes to ensure that your application respects all the available settings.

Test your application with black and white, high contrast themes and confirm that all information is still conveyed correctly. If you don't have a suitable high contrast GNOME theme available to test, print off some screenshots in black and white (not grayscale) and make sure all the important information is still visible— this will approximate what a high contrast theme user will see.

#### Animação

Ensure you have implemented an option to turn off any animation in your application (for accessibility reasons), and that it is working as designed. Turn the animation off. Confirm that all information is still conveyed correctly.

### Things You Can Do With Other People

#### Get Early Feedback

It's always tempting, but don't start coding your interface straight away. Sketch out some ideas on paper first, or in Glade or HTML if you prefer. (But don't be tempted add any functionality at this point if you do it this way!)

Show these prototypes to other people— the GNOME mailing lists and IRC are ideal for finding likely candidates. Ask them to use these prototype interfaces to run through some of the scenarios you came up with earlier. You'll probably get questions like "how would I do X", "which menu is Y on"... these questions will help you think about the interface from the user's viewpoint. You'll probably also get a few suggestions about how to do things differently— these ideas may or may not turn out to better than yours, but any idea from a potential user is worth considering!

You should also consider seeking opinions from the GNOME Usability team. They have designed many user interfaces before and may be able to spot potential problems at this early stage, before you take your design too far to change easily.

Once you've decided on the basic interface design and have started coding parts of it, find somebody to try it out again— it doesn't have to be the same person. You'll probably find some more problems that were hard to see on your static paper prototype. By finding these now, it's usually not too late to fix them without too much trouble.

#### Internacionalização e localização

If you intend your application to be translated into different languages, show draft designs of your application to the GNOME Translation Team. They'll help you find potential translation problems, such as not leaving enough space for translated labels, shortcut keys that cause problems on a different keyboard layout, or using new terms in your app that are hard to translate.

If possible, try out your application with users from the locales you are targeting. This will help you determine whether users understand how to use the application, if they perceive the graphics and colors the way you intended, and if there are words or images in the application that may cause offence to users of that locale.

## Credit

(lists in alphabetical order, if you were accidentally omitted please email the authors or file a bug)

### Active Authors

- Calum Benson, calum.benson@sun.com

- Bryan Clark, clarkbw@gnome.org

- Seth Nickell, seth@gnome.org

### Additional Illustrations

- Mihai Anca, ropiku@gmail.com

- Denis Anisimov, genius@s146.net.ru

- Wouter Bron, wousser@gmail.com

### Retired/Inactive Authors

- Coleen Baik

- Adam Elman

- Colin Z. Robertson

- Maciej Stachowiak

### Reviewers and Contributors

- Chip Alexander

- Kathy Fernandes

- John Fleck

- Andrea Mankoski

- Nils Pederson

- Sebastian Rittau

- Christian Rose

- Sharon Snider

- Suzanna Smith

- Matthew Thomas

This bibliography lists books and other resources for software engineers, user interface designers, and human factors specialists, arranged by topic and without a particular ordering. The final section of the bibliography contains information about useful online resources and organizations.

### General Design

Dreyfuss
, Henry

### Designing for People

    New York, NY

: allworth press, 2003 A reprint of the 1960s design classic by the designer of everything from the modern airplane cabin to the Bell telephone. Perhaps the best book for introducing the general concerns and thought patterns of design (industrial, product, or interaction), as well as an entertaining read.
Mandel
, Theo.

### The Elements of User Interface Design

.

    New York, NY

: Wiley Computer Publishing, 1997. A useful book covering all the basics and a wide scope of environments and new developments like interface agents, wizards, voice interaction, social user interfaces and web design.
Norman
, Donald A.

### The Design of Everyday Things

.

    New York, NY

: Doubleday, 1990. An exceptional and entertaining book about the design behind simple daily things.

### Graphical Design

Horton
, William

### The Icon Book: Visual Symbols for Computer Systems and Documentation

.

    New York, NY

: John Wiley & Sons, 1994.
Misjksenaar
, Paul and Piet Westendorpp.

### Open Here: The Art of Instructional Design

.

    London, UK

: Thames & Hudson, 1999
Mullet
, Kevin and Darrell Sano.

### Designing Visual Interfaces: Communication Oriented Techniques

.

    Englewood Cliffs, NJ

: Prentice Hall, 1995.
Rubin
, Jeffrey.

### Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests

.

    New York, NY

: John Wiley & Sons, 1994.
Tufte
, Edward R.

### Envisioning Information

.

    Cheshire, CT

: Graphics Press, 1990 The second classic work on envisioning information by Tufte.
Tufte
, Edward R.

### The Visual Display of Quantitative Information

. Reprint ed.,

    Cheshire, CT

: Graphics Press, 1992 The first classic work on envisioning information by Tufte.
Williams
, Robin.

### The Non-Designer's Design Book: Design and Typographic Principles for the Visual Novice

.

    Berkeley, CA

: Peachpit Press, 1994.

### Usability

Arlov
, Laura.

### GUI Design for Dummies

.

    Foster City, CA

: IDG Books Worldwide, 1997.
Cooper
, Alan and Reimann, Robert.

### About Face 2.0 : The Essentials of User Interface Design

. John Wiley & Sons, 2003.
Cooper
, Alan.

### The Inmates are Running the Asylum : Why High Tech Products Drive us Crazy and How to Restore the Sanity

. SAMS, 1999.
Isaacs
, Ellen and Alan Walendowski.

### Designing from Both Sides of the Screen

.

    Indianapolis, IN

: New Riders Publishing, 2001.
Nielsen
, Jakob.

### Usability Engineering

.

    San Francisco, CA

: Morgan Kauffman, 1993.
Tognazzini
, Bruce.

### Tog on Interface

.

    Reading, MA

: Addison-Wesley, 1992.