Regras para Interface de Utilizador

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

Para te ajudar a atingir estes objectivos, estas guias vão cobrir os elementos base da interface, como os deves usar de forma eficiente, e como fazer a tua aplicação integrar com o restante desktop. A coisa mais importante que tens que te lembrar, é que estas linhas mestras estão cá para ajudar e não para complicar o teu trabalho.

No entanto, tenha em atenção que isto é uma linha de orientação, não um livro de regras. Novos, supreendentes paradigmas aparecerão cada dia e mais estarão à espera para serem descobertos. Isto é um documento vivo que pode e será alterado.

Para secções que ainda não estão escritas, por favor procura no O GNOME HIG

Filosofia de Design

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

O Que o Design Não É

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

  1. Design não é algo que se adicione no fim de ter um produto pronto. para melhor compreenderes, estás sempre a desenhar aquilo que queres construir. Isto é uma parte intrínseca de construir alguma coisa. Design não é apenas o aspecto visual de uma coisa. Quando decides adicionar um botão que faz uma acção, isto é design. Tomaste uma decisão de acrescentar um botão, com um icone ou uma etiqueta de texto, onde este botão foi colocado, a sua dimensão e cor. Decidir é fazer design.

  2. Design não é a tua opinião! design é quantificável. Um design vai cumprir um objectivo de forma mais eficiente que outros. Pensa em tipos de bicicleta. Uma bicicleta dobrável tem um conjunto de objectivos de design diferentes de uma bicicleta de montanha. Coisas como a dimensão, peso, ou o tipo de pneu são factores importantes a ter em conta para os objectivos do utilizador. Como já compreendemos que o Design trata de resolver problemas específicos, temos também que compreender que podemos comparar a eficácia de dois designs a resolver estes problemas.

  1. Design Não É Floreados, Aral Balkan
  2. Design Não É Subjetivo, Jeff Law

Concisão

Trabalha sempre com o propósito de tornar a tua app imediatamente perceptível. A função principal da app deve ser evidente. Podes conseguir isto de uma série de maneiras, mas uma das melhores formas é manteres a app sob o princípio da concisão.

Evita funcionalidades em excesso

é muitas vezes tentador continuar a adicionar mais e mais funcionalidades à tua app. No entanto, é primordial reconhecer que cada nova funcionalidade tem um preço. Especificamente, cada vez que adicionas uma nova funcionalidade:

Pense em Módulos

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

Evitar Configuração

Se possível, evita completamente exigir configurações ou preferências na tua app. Oferecer este tipo de conteúdo é normalmente uma forma fácil de fugir a decisão de fazer bom design sobre o comportamento da app. Mas tal como os problemas ou excesso de funcionalidades, preferências implicam mais código, mais bugs, mais testes, mais documentação e mais complexidade.

Constrói a app para uma experiência imediata.

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

Pergunta ao Sistema Operativo.

Obtém o máximo de informação possível de forma automática. Em vez de questionar o utilizador pelo seu nome e localização, tenta obter esta informação do sistema. Isto corta bastante o número de coisas que o utilizador tem que fazer, antes mesmo de usar a tua app, e faz a tua app parecer inteligente e integrada.

Precisa Mesmo?

Pergunta a ti mesmo se a opção de configuração que estás a acrescentar faz sentido para o utilizador. Não peças nunca ao utilizador para tomar decisões de design.

Quando precisas mesmo de

Mantém as coisas contextualizadas. Em vez de esconderes preferencias numa caixa de diálogo específica, pensa em apresentá-las no contexto com os objectos que elas afetam. (e.g. as opções de shuffle ou repetir uma musica aparecem ao lado dos controlos da app de musica).

Se a tua app necessita de uma configuração antes de ser usada (e.g. um cliente de correio electrónico), apresenta esta configuração dentro da janela principal, como se tratasse de um ecrã de boas vindas. Mais uma vez, certifica-te que esta configuração é mesmo necessária. Adicionar ecrãs de configuração desnecessários desvia o utilizador do seu propósito inicial, que o levou a abrir a tua app.


Veja também:

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

Documentação Minimalista

A maioria dos utilizadores não quer ler um documento extenso de ajuda antes de usar a tua app. Em vez disso, têm como dado adquirido que a tua app é intuitiva e simples para a sua compreensão sem necessidade de assistência.

Usa uma linguagem compreensível.

Evita jargão técnico, e assume um nível de conhecimentos perto do zero. Isto permitirá que a app seja simples e auto-explicativa.

Inclui explicações não técnicas em vez de mensagens de erro crípticas. Se alguma coisa corre mal, uma explicação simples do que ocorreu e do que fazer para corrigir a situação deve estar presente.


Para mais informação podes ler Estilos de escrita.

Workflow de Utilização

O design visível é uma grande parte da experiência de utilização, mas a forma como o utilizador interage com a aplicação - Workflow de Utilização- também o é. Nesta secção vamos cobrir alguns passos importantes de um processo de trabalho típico.

Experiência de Primeira-Abertura

Configuração Necessária

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

Rapidez de Abertura

A primeira vez que o utilizador corre a tua app, é quando fica com a primeira impressão; É a melhor altura para mostrares a sua fluidez e o quão bem desenhada está. Se a tua app precisa de configurar coisas em plano de fundo, antes de lançar visualmente a interface, vai dar ao utilizador a impressão de que é lenta, ou que vai demorar sempre imenso tempo a arrancar. Deves-te focar em fazer a janela da app aparecer rapidamente, e pronta a usar, e a fazer as tarefas em background, por detrás do pano. Se estas tarefas estão a bloquear a utilização (e.g. o utilizador não pode usar algumas das suas funcionalidades), mostra algum tipo de indicação de que estão a ocorrer estas tarefas longe da vista, e tira a "sensibilidade" aos items da interface que não vão responder (ver Conceitos de Widgets).

Dar as Boas Vindas ao Utilizador

Se não há conteúdo para exibir, disponibiliza acções que o utilizador possa desempenhar usando um Ecrã de boas vindas. Permite-lhes abrir um documento, adicionar uma conta, importar um CD, ou o que fizer mais sentido no contexto da tua app.

Restabelecer a App

Se um utilizador faz um "reset" explícito da aplicação (e.g. apagando todas as músicas da biblioteca, ou removendo todas as contas de e-mail) deverás apresentar a app no seu estado inicial.

Lançamento Normal

Quando um utilizador lança uma aplicação, está a realizar uma acção explícita e espera uma resposta rápida, senão imediata. Deverás focar-te em três áreas principais no lançamento: Velocidade, O que fazer a seguir - tem que ser óbvio - e o estado.

Rapidez

Como já foi dito antes, a rapidez, especialmente ao lançar uma aplicação, é muito importante. Deve haver tão pouco atraso quanto possível entre o momento em que um utilizador decide lançar uma aplicação e o instante em que pode começar a usá-la. Se a tua aplicação requer uma tela de arranque, é porque não estás a fazê-la bem.

Evidência

Quando o utilizador lança a tua app, tem que lhe ser evidente o que fazer a seguir. Isto é conseguido seguindo as outras linhas mestras do design (assegurando que a app é consistente com as demais) e demonstrando de forma evidente quais as acções disponíveis logo à partida. Se a app apresenta items, como músicas ou e-mails, dê acesso direto aos vários items existentes mostrando-os assim que a app lança. Se não existirem items abertos de sessões anteriores, deverá propor abrir um item, ou criar um novo item (e.g. um documento) usando um ecrã de boas vindas.

Estado

Se o utilizador já usou previamente a tua app, tipicamente o melhor será restaurar a sessão ao estado em que este a deixou. Isto significa que a app deve aparecer aberta exatametne onde o utilizador a deixou para que este possa seguir caminho. No caso de uma aplicação de música, deve abrir na última view, e a música que tocava na altura deverá estar em pause. Num editor de documentos, isto significa abrir no mesmo documento, e com o cursor exatamente na mesma posição na página.

Proporcione Sempre Um Voltar Atrás

Por vezes um utilizador pode levar a cabo uma acção destrutiva ou irreversível. Em vez de apresentar um aviso, as aplicações devem apresentar uma hipótese para desfazer as alterações, durante um intervalo de tempo apropriado. Alguns exemplos óptimos deste comportamento são:

Este comportamento deve ser usado apenas em situações especiais, implementando um tempo de buffer reduzido entre o dar a indicação de realizar a acção e o realizar a mesma. Este comportamento vai contra a ideia de se manter a experiência rápida/imediata, em que a app deverá apresentar-se sempre como se a acção se realizasse assim que o utilizador dá esta instrução.

Este comportamento consegue o melhor equilíbrio entre manter-se fora do caminho dos utilizadores enquanto se certifica que eles não fazem algo que não seja intencional. É importante manter a ação desfazer não intrusiva mas no entanto simples e intuitiva; uma maneira comum de o fazer é usar uma barra de informação, embora outros métodos possam também ser apropriados.


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

Sempre Gravado

Os utilizadores devem sentir-se confiantes quando usarem elementary; devem saber que tudo o que veem é guardado e atualizado.

As apps no elementary devem operar em volta de um estado sempre-guardado. Isto significa que alterações que o utilizador faça são instantaneamente aplicadas e visíveis; que fazer o utilizador guardar manualmente coisas é um comportamento antigo ou algo muito específico.

Por exemplo, um diálogo de Informação de Música deve atualizar a informação da faixa instantaneamente, sem que o utilizador tenha de pressionar o botão de guardar; preferências de utilizador devem ser aplicadas logo que o utilizador manipula o widget relevante, e fechar uma app deve significar que reabri-la retornará o utilizador ao ponto onde a deixou.

A Fechar

Quando um utilizador fecha uma app, é tipicamente porque já acabou de desempenhar a tarefa em mãos, e quer que a app saia do caminho.

Guardar o Estado

As apps devem gravar o seu estado quando são fechadas para que possam ser reabertas exatamente no sítio onde o utilizador as deixou. Idealmente isto não deverá ser diferente de minimizar e maximizar a app; ou seja todos os elementos deverão ser gravados, inclusivamente documentos, o ponto do scroll, o historico de reversão de acções, etc.

Tarefas de Segundo Plano

Se fizer sentido que a app complete tarefas de background depois da janela fechada, estas deverão ser realizadas no imediato. Se a a app realiza tarefas repetitivas (e.g. um cliente de e-mail), as tarefas de background deverão ser realizadas por um daemon em separado que não dependa do estado da aplicação principal.

Fechar a Janela da Aplicação

Não é desejável que uma janela de app simplesmente minimize em vez de fechar quando o utilizador a tenta fechar. Em vez disso a janela da app deve ficar "escondida". Se fizer sentido para continuar um processo nos bastidores (tal como descarregar/transferir, tocar música, ou executar um comando do terminal) o processp da app deve continuar com a tarefa e fechar quando a tarefa estiver concluída. Se não for imediatamente aparente que o processo completou (como no descarregar/transferir ou comandos do terminal), a app pode mostrar uma notificação informando o utilizador que o processo completou. Se for aparente, tal como na música, nenhuma notificação é necessária.

Re-Abertura da Janela da App

Se o utilizador re-abrir a app enquanto o processo de bastidor ainda estiver em execução, a app deve estar exactamente no sítio onde deveria estar se a janela estivesse ficado aberta durante o tempo todo. Por exemplo, o terminal deve mostrar qualquer resultado, o reprodutor de música deve estar na mesma página quando foi fechado, e o navegador deve voltar à página onde estava previamente. Para mais detalhes, veja a discussão do estado da app num Lançamento Normal.


Ver também: That's It, We're Quitting por Matthew Paul Thomas

Integração no Ambiente de Trabalho

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

Lançadores de App

O método principal de descobrir e usar a sua aplicação será através do lançador de aplicações que encontrará no Slingshot ou na dock. Por forma a fornecer estes lançadores, terá de instalar um ficheiro .desktop apropriado com as informações da sua aplicação. Isto inclui fornecer o seu lançador com o nome da aplicação, colocá-lo na categoria correta, atribuir-lhe um ícone, etc.

Ficheiros do tipo .desktop seguem a Especificação Desktop Entry. Devem ser instalados em /usr/share/applications. Os utilizadores podem criar os seus ficheiros de lançamento colocando ficheiros deste tipo em ~/.local/share/applications.

O conteúdo dos ficheiros .desktop deverão respeitar os seguintes parâmetros:

O Título é um GenericName que te permite Comentar.

Título

Não deverá incluir termos descritivos no título. Por exemplo, Dexter deverá ser intitulado de "Dexter", não "Contatos Dexter". Midori é simplesmente "Midori", não "Web Browser Midori". Ao invés, no ficheiro .desktop da sua aplicação, utilize a linha GenericName para o nome e a linha Comment do mesmo para uma frase longa e mais descritiva.

NomeGenérico

Se a tua app é facilmente caracterizada ou descrita apenas com um nome genérico, deves usar essa palavra no atributo GenericName no seu ficheiro .destkop. Se consegues dizer " a minha app é um(a) ____," então aquilo que colocarias no espaço em branco é um excelente GenericName. Por exemplo o Maya é um calendário, por isso o seu nome genérico é simplesmente "Calendário".

Não deves incluir artigos (o, a de ) ou as palavras "programa","app" ou "aplicação" no nome genérico da app.

O nome genérico deve estar em Title Case e pode ser usado por todo o sistema para melhor descrever e categorizar a tua app.

Comentário

O sistema usa o atributo "Comment" (disponível no ficheiro .desktop) para informar o utilizador de forma sucinta, o que poderá fazer com a app. Deverá ser uma frase curta iniciada por um verbo e contendo os substantivos associados à tua app. Deixamos aqui alguns exemplos de comentários apropriados:

O comentário deve ser escrito em Sentence Case, não deve incluir a pontuação final (ponto final, exclamação ou interrogação), e deverá ser curta e simples, descrevendo a utilização primária da tua app.

Categorias

As seguintes categorias podem ser usadas para ajudar na busca ou procura pela sua app:

Para mais info, consulte a especificação do menu entry no FreeDesktop.Org.

Palavras-chave

Podes também incluir palavras chave no teu ficheiro de lançamento para ajudar o sistema a encontrar a app a partir da pesquisa. Estes seguem as convenções da "X-GNOME-Keywords" (para o lançador da app) e "X-AppInstall-Keywords" (para o instalador). Por exemplo, um navegador de internet pode incluir "Internet" como palavra chave, mesmo que não seja este o nome da app, nome genérico ou descrição. Assim a app será apresentada como resultado de uma pesquisa por "internet". Deixamos aqui mais exemplos:

As palavras chave deverão ser palavras únicas (em Title Case) e separadas com um ponto e vírgula.


Ver também: Desktop Entry Specification da FreeDesktop.org

Contractor

Contractor é um serviço e protocolo usado para expor facilmente serviços entre aplicações. Permite que uma app interaja com várias outras apps/serviços sem ser necessário escrever código de suporte e integração. Adicione simplesmente suporte ao contractor, e qualquer serviço registado no contractor fica disponível para a sua aplicação. A tua app pode integrar com o contractor de duas formas:

Apresentar resultados do Contractor

A forma mais típica de apresentar resultados do contractor é na forma de menu. Tem o seguinte em consideração quando o fazes:

Integração no Dock

Integra a tua app com o Communicate da da doca do Pantheon, para comunicar imediatamente o seu estado ao utilizador.

Barrasdeprogresso

A barra de progresso não pode ter ambiguidade na sua utilização, sendo sempre referente a uma única tarefa. Pode ser usada para indicar o estado de uma transferência de ficheiros ou um processo longo como codificar. A barra de progresso não deve ser usada para um conjunto de múltiplos tipos de acção.

Crachás

O crachá mostra uma contagem de items actuáveis que a tua app gere. tem o propósito de informar o utilizador de que há items que requerem a sua atenção, ou acção, sem ser intrusivo. É uma notificação passiva. O crachá não deve mostrar totais, ou contadores muito estáticos. Se o crachá não for facilmente descartado quando o utilizador vê a tua app, é provável que o seu uso não esteja a ser o mais correto.

Indicadores de Sistema

O indicadores são pequenos icones que vivem no painel de topo. Dão ao utilizador um sítio para uma referência rápida de opções ou eventos. Clicar neste icone mostra um menu pequeno com acções disponíveis para o utilizador.

A Sua App Precisa De Um Indicador de Sistema?

A área dos indicadores é conhecida por rapidamente ficar cheia e ter um comportamento inconsistente. Assumindo que os utilizadores vão instalar muitas apps de terceiros, precisamos de ter atenção ao número de indicadores que criamos e ao seu comportamento. Tem em atenção que nem todas as app necessitam de um indicador. Só mesmo um conjunto reduzido de aplicações vai colher benefícios. Não precisas de um indicador se:


Ver também: Farewell To The Notification Area por Matthew Paul Thomas

Widgets Contentores

Janelas

Janelas são a fundação sobre a qual a tua aplicação é construída. Providenciam um tipo de área de trabalho com algumas acções pré estabelecidas, como por exemplo fechar a app, redimencionar a app, etc. Apesar dos utilizadores verem as janelas como iguais, existem vários tipos de janelas no elementary OS. É importante conhecer os tipos de janela existentes, qual o seu comportamento genérico, e comportamentos específicos de alguns tipos de janela. Esta secção irá falar sobre os diferentes tipos de janela no elementary OS. Apesar de cada tipo de janela ser diferente, imagina-os como subclasses de uma única janela. Quando não indicado o contrário, todos funcionam da mesma forma.

Títulos de Janela

Quando lidares com os títulos das janelas, considera que o seu objectivo é facilitar a distinção entre várias janelas abertas. Um bom título providencia uma descrição que facilite ao utilizador fazer uma selecção. Lembre-se disto quando:

Diálogos

24
Icone de janela de aviso

O texto principal fornece informação básica e sugestões

O texto secundário fornece mais detalhes. Também inclui informações que explica quaisquer consequências não percetíveis de ações.

24
Cancelar
Acção Sugerida

Texto de Alerta

Um alerta contém texto primário e secundário.

O texto principal contém um breve resumo da situação e oferece uma acção sugerida. Este texto deve usar a classe CSS primary.

O texto secundário promove uma descrição mais detalhada da situação, e descreve potenciais efeitos secundários das acções disponíveis. É importante que notes que um utilizador deverá necessitar apenas do texto primário para tomar uma decisão, e deverá usar este texto secundário apenas para clarificação. Este texto deverá ser colocado numa segunda linha abaixo do texto primário e deverá usar a dimensão e peso da fonte por omissão.

Faz com que o texto primário e secundário sejam seleccionáveis. Isto facilitará ao utilizador fazer cópia do mesmo e colar numa outra janela, como por exemplo numa mensagem de e-mail.

Ordenação de Botões

"OK" não é Okay

Quando apresentas uma caixa de diálogo ao utilizador, usa sempre nomes de acção explícitas como "Gravar...", "Desligar", etc. Considera que usar "OK" permite ao utilizador avançar sem saber exatamente que acção é que está a autorizar. Nem todos os utilizadores vão ler a questão ou informação presente no diálogo. Usar nomes específicos de acções vai dificultar a realização de uma acção não intencional, e poderá influenciar o utilizador a ler a informação apresentada antes de fazer uma selecção.

Diálogos de Preferências

Caixas de diálogo com preferências devem ser "Transcientes", mas não Modais. Quando um utilizador altera uma propriedade, esta alteração deve ser imediatamente visível na Interface de utilizador. Se a caixa de diálogo for Modal, esta poderá bloquear a visão (e a interacção) do utilizador com a alteração. Ao tornar esta caixa transciente, mantemos a caixa no topo para acesso facilitado, mas também permitimos ao utilizador avaliar e possivelmente reverter as alterações sem ter que fechar e voltar a abrir a caixa de diálogo de preferências.


Ver também:

  1. Why 'Ok' Buttons In Dialog Boxes Work Best On The Right por UX Movement
  2. Why The Ok Button Is No Longer Okay por UX Movement
  3. Should I use Yes/No or Ok/Cancel on my message box? em UX StackExchange
  4. Where to Place Icons Next to Button Labels por UX Movement

Popovers

Popovers são como um diálogo contextual. Apresentam informação diretamente relacionada com algo que foi clicado, e desaparecem quando se clica fora das mesmas, tal como menus.

Este tipo de janela deve ser usado quando um utilizador pretende realizar uma acção rápida, sem sair da interface principal. Alguns exemplos de popover pode ser o adicionar um contacto a um e-mail, adicionar um bookmark num navegador, ou apresentar uma lista de descargas ou transferência de ficheiros.

Popovers não devem ser usados quando apresentando apenas uma simples lista de items, Em vez disto usa um menu. Da mesma forma não uses um popover se o utilizador vai dispender mais do que alguns segundos a usar as opções disponíveis. em vez disso usa uma janela de diálogo. Lembra-te que as janelas de popover são contextuais e deve-se relacionar com o elemento da interface a partir do qual são geradas.

Barra de Ferramentas

Uma barra de ferramentas é útil para apresentar ao utilizador um acesso rápido às funcionalidades mais usadas da aplicação. Além de botões, esta barra é um dos elementos de UI mais usados. Pode parecer um simples contentor, mas é importante que permaneça consistente no seu uso e organização.

Ordenação de Items da Barra de Tarefas

Os elementos da barra de ferramentas devem estar organizado com os objectos mais importante a esquerda, e os menos à direita, com o AppMenu sempre no extremo direito da barra. Se tens muitos elementos, poderá ser apropriado dividir os mesmos em grupos, usando para tal espaço em branco entre cada grupo. Lembra-te que quando apresentados com escrita inversa - da direita para a esquerda - esta barra também estará invertida.

Elementos do Kit de Ferramentas da IU

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

Conceitos de Widget

Antes de apresentarmos todos o widgets disponíveis no elementary OS, precisamos de cobrir alguns conceitos básicos que lhes são comuns. Usar estes conceitos corretamente vai criar uma experiência muito mais unificada, e evitar-te a ti, horas perdidas a ler bug reports!

Controlos Que Não Fazem Nada

Um erro comum que os developers fazerm é criar controladores que aparentemtente fazem...nada. Tem em mente que queremos apresentar um ambiente de trabalho onde os utilizadores se sintam confortaveis. Um utilizador curioso vai interagir com um controlo na esperança de ver uma acção realizada no imediato. Quando um elemento não produz qualquer efeito visível, isto cria confusão e mesmo medo ("uh.oh... não sei o que acabei de fazer!"). Em alguns casos, estes controlos que nada fazem são lixo que apenas adicionam complexidade a tua UI.

Considere o botão "limpar" presente em campos de pesquisa. Este botão só aparece quando é relevante e necessário. Ao clicar neste botão quando o campo já está limpo, essencialmente, não faz nada.

Sensibilidade

Por vezes não faz sentido ao utilizador interagir com um widget até que algum pre-requisito seja verificado. Por exemplo, não faz sentido permitir ao utilizador carregar em "avançar" num browser, quando não existe uma história de visitas de onde se voltou. Neste caso, deverá retirar a sensibilidade a este botão, para evitar que um utilizador o invoque na expectativa de ver um resultado... e nada acontecer.

É preferível retirar a sensibilidade ao widget em vez de o retirar por completo. Tornar o widget insensível informa o utilizador que a funcionalidade está disponível, mas apenas após se verificar uma certa condição. Esconder o widget pode dar a impressão de que a funcionalidade não está disponível, ou pode levar o utilizador a pensar que uma funcionalidade "desapareceu".

Widgets Escondidos

P oderá fazer sentido esconder um widget quando este apenas faz sentido num certo contexto (não como indicador de uma acção a ser desempenhada). Pensemos num exemplo com hardware. Poderá não fazer sentido apresentar as opções de multi-monitores se o computador tiver apenas um ecrã conectado. Retirar apenas a sensibilidade a estes controlos não contribui positivamente para passar qualquer ideia ao utilizador. e pode gerar confusão. Outra excepção a esta regra é um widget que o utilizador apenas procurará num contexto, como o exemplo do "botão de limpar" acima descrito. Finalmente, lembra-te que os items sem sensibilidade continuarão a ser interpretados pelos leitores de ecrã e outras tecnologias de assitência a leitura, enquanto que os escondidos não.

Espaçamento

Alinhamento


Ver também: Form Label Proximity: Right Aligned is Easier to Scan por UX Movement

Barras de Informação

As Barras de Informação oferecem informação contextual e acções, de acordo com o seu nível de importância.

É importante determinar a importância ou tipo de Barra de Informação a usar. Existem quatro tipos de Barras de Informação disponíveis:

Ecrã de Boas Vindas

O Ecrã de Boas Vindas é uma forma amigável de ajudar utilizadores a começarem com a sua app.

Utilização

Tipicamente o Ecrã de Boas Vindas é usado para apps tipo Noise ou Scratch onde se tem de importar ou criar objetos numa biblioteca antes de poder interagir com os mesmos. Isto proporciona aos seus utilizadores um caminho claro para começar e aponta quaisquer passos imediatos que eles devem tomar antes da sua app se tornar útil.

Se a tua app permite que o utilizador limpe a biblioteca, certifica-te que o retorna ao ecrã de boas vindas em vez de uma lista vazia.

Etiquetagem

O Ecrã de Boas Vindas consiste em dois conjuntos de etiquetas:

Iconografia

Agrupado com cada ação está um ícone que ajuda a identificá-la rapidamente. Na maior parte do tempo estes serão ícones de Ações, mas pode usar Ícones de Sítios quando importar ou definir uma localização e até mesmo ícones de Apps se tiver de abrir um utilitário de configuração.

Lista de Fontes

Uma lista de fontes pode ser usada como uma forma de navegação de topo. Estas listas são úteis para apresentar diferentes locais, bookmarks ou categorias dentro da sua app.

Secções

Uma lista de fontes pode ser separada em várias secções colapsáveis, cada uma com o seu cabeçalho. Por exemplo, um gestor de ficheiros poder ter uma secção para sítios masi frequentes, outra para dispositivos de armazenamento externos, e uma secção para equipamentos em rede. Estas secções ajudam a agrupar items relacionados na lista de fontes, e permite ao utilizador a esconder secções que não usa.

Evita secções expansíveis em cascata se possível. Se te vês na situação de usar este tipo de arrumação, poderá ser melhor repensar as secções que escolheste.

Hierarquia

A hierarquia é importante nas listas de fontes, tanto dentro do teu widget, como no compto geral da tua aplicação.

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

Uma Lista de Fontes fica do lado esquerdo de uma janela (do lado direito para RTL). Uma vez que o utilizador estrutura a sua leitura desta forma, a barra lateral vê a sua importancia reforçada (uma vez que vem primeiro) face aos demais conteúdos.

Botões

OS botões são dos widgets mais importantes de compreender, uma vez que a tua app certamente os vai usar.

Botões de Ferramentas

Etiquetagem

Os botões de ferramentas são quase sempre exclusivamente icónicos, e não têm borda. Não devem ser acompanhados por uma etiqueta.

Tooltips

Todos os botões deverão ter tooltips, uma vez que não contêm etiquetas. Isto dá assistência ao utilizador com dificuldades visuais, bem como providencia uma descrição para um icone que não seja reconhecido à primeira. Estas tooltips devem ser escritas em Sentence Case - maiúsculas e minúsculas.

Tal como as etiquetas textuais dos botões, estas tooltips deverão descrever claramente o que acontecerá quando o botão for pressionado.

Botões de Texto

Etiquetagem

O texto das etiquetas dos botões deverá ser sempre em TItle Case - Primeira letra de cada palavra em maiúsculas.

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

"Remover Conta", "Transferir Para o Portátil", e "Importar 20 Canções" são boas etiquetas.

"OK", "Obtenha mais armazenamento!" e "Bateria Baixa" não são boas etiquetas para botões. A "Obtenha mais armazenamento!" usa uma capitalização incorrecta, e pontuação desencessária. Com os outros exemplos não fica bem claro o que acontece quando estes são pressionados.

Tooltips

Uma vez que os botões têm uma etiqueta clara e explícita, é normalmente desencessário acrescentar uma tooltip.

Botões Interligados

Utilização

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

Etiquetagem

Estes Botões Interligados nunca deverão conter icones coloridos. Apenas icones simbólicos de 16px OU texto. Nunca deves misturar texto e icones.


  1. Why The OK Button Is No Longer Okay por UX Movement
  2. Should I use Yes/No or Ok/Cancel on my message box? em UX StackExchange

AppMenu

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

Utilização

Deverás equancionar se a tua app necessita deste widget. Apesar da maioria das apps terem um, a tua app pode não necessitar do mesmo.

Ao adicionar items ao teu AppMenu, considera o seguinte:

Campos de Pesquisa

Aplicações que suportam pesquisa ou filtragem de conteúdo devem incluir um campo de pesquisa no lado direito da barra de ferramentas. Isso dá aos utilizadores um lugar previsível para ver se suporta ou não a função pesquisa, e uma localização consistente a quem pretende procurar. O Gtk+ fornece um widget complexo conveniente para este efeito chamado Gtk.SearchEntry.

Destinguir entre pesquisar e procurar

Pesquisa usa-se para filtrar os conteúdos de uma biblioteca , i.e. Música ou videos, em busca de um conteúdo específico. É normalmente despoletada quando se começa a escrever numa vista de biblioteca.

Pesquisar destina-se a evidenciar instancias de uma palavra, e.g. num editor de texto, página web ou terminal. É despoletada ao usar o teclado (CTRL+F) ou com um ícone de pesquisa. A barra de pesquisa aparecer por baixo do cabeçalho e tem acções relevantes como seguinte, anterior, evidenciar todos, etc. Poderá conter também outras acções como substituir ou ir para a linha

Comportamento

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

Etiquetagem

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

A maioria dos campos de pesquisa deve usar o formato "Pesquisa OBJECTO" onde OBJECTO é o que vai ser pequisado, como Contactos, Contas, etc.

Se o campo de pesquisa interage com um motor de busca, a dica textual deverá ser o nome do serviço a usar como "google" ou "Yahoo!".

Caixas de Verificação & Interruptores

Caixas de Verificação

As Caixas de Verificação oferecem uma forma para o utilizador seleccionar items de uma lista.

Utilização

Usa Caixas de Verificação quando o utilizador tem que fazer uma escolha de items. Certifica-te que o utilizador pode ativar a Caixa de Verificação clicando na etiqueta que a acompanha.

Etiquetagem

As etiquetas associadas com as Caixas de Verificação devem conter nomes, ou frases nominativas.

Interruptores

Interruptores oferecem uma forma ao utilizador para activar e desativar algumas funcionalidades ou comportamentos "ligado" ou "desligado".

Utilização

Não uses interruptores para incluir items relacionados como parte de uma lista, usa uma Caixa de Verificação. Pensa no interruptor como actuante em serviços independentes, e as caixas de Verificação para incluir objetos numa lista. Isto é uma distinção importante a fazer.

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

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

Etiquetagem

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


Ver também: 3 Ways to Make Checkboxes, Radio Buttons Easier to Click por UX Movement

Livro de Notas

Blocos de notas são um tipo de widget que permite exibir uma de múltiplas páginas numa aplicação, também conhecidas por "tabs" ou (separadores).

Bloco de Notas Estático

Um Bloco de Notas estático é um conjunto pequeno de separadores estáticos, normalmente vistos em ecrãs de preferências. Estes aparecem como botões interligados centrados no topo da área de conteúdo. Este Bloco de Notas deverá ter duas a 5 entradas.

Bloco de Notas Dinâmico

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

Iconografia

A iconografia é uma parte chave do elementary OS. Os icones são a principal componente da Interface que o utilizador vai usar; é o que dá vida ao sistema, e permite ao cérebro humano reconhecer o que está a ver.

Forma

Os teus icones devem ter uma forma/silhueta distinta para melhorar o seu reconhecimento. Esta forma não deve ser muito complicada, mas o icone não dever ser sempre um rectângulo arredondado.

Ícone Dialogo de AvisoÍcone Conversa Ícone FotosÍcone VideosÍcone Contas OnlineÍcone Terminal

Metáforas

Se estás a criar um icone para um equipamento físico ou tipo de ficheiro (como os do MimeType ou Dispositivo), a sua forma é normalmente a representação visual dos seus equivalentes no mundo real. Por exemplo o icone da camara fotográfica, é uma camara fotográfica estilizada.

Ícone CameraÍcone Disco RigidoÍcone RatoÍcone de PacoteÍcone Texto HTMLÍcone Computador

Icones de Acção.

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

Ícone RetrocederÍcone AvançarÍcone de Exportar DocumentoÍcone de ImprimirÍcone de GravarÍcone de ApagarÍcone de CortarÍcone de desfazerÍcone de InverterÍcone de ReproduzirÍcone de Nova EtiquetaÍcone de Menu

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

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

Dimensões dos Icones

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

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

Desenha cada ícone no tamanho em que é suposto ser visto. Por outras palavras, não desenhes o ícone e redimensiones para os restantes tamanhos, o melhor resultado é conseguido quando cada ícone é desenhado individualmente. Para mais informação acerca desta prática (chamada "pixel-fitting") e a sua importância, recomendamos a leitura do artigo de Dustin Curtis, Pixel-fitting.

Paleta de Cores

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

Ícone de MailÍcone de Leitor RSSÍcone de Navegador WebÍcone FotosÍcone de RedeÍcone de Calenário

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

Icones Simbólicos

Ícones Simbólicos são ícones de sistema comuns, que simbolizam ficheiros, equipamentos ou directorias e são também usados para representar acções comuns como cortar, copiar ou gravar.

Cada Ícone Simbólico é uma forma reduzida da sua versão colorida. Este desenho minimalista assegura legibilidade e clareza mesmo em dimensões reduzidas.

Simbólicos Versus Ícones Coloridos

Coloridos Vs. Ícones Simbólicos

O uso de ícones Coloridos ou Simbólicos não é intermutável. Ambos têm usos apropriados.

Icones coloridos devem ser usados para:

Icones Simbolicos devem ser usados para:

Composição

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

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

Ter em atenção estas três marcas enquando desenhas o icone, significa que podes colocar os elementos com a garantia de que os icones aparecerão mais consistentes quando juntos. Nota, por exemplo, como alguns elementos do icone do Terminal e dos Videos ficam alinhados relativamente a linha de meia altura.

Medidas Comuns

Se estás a desenhar um icone com o formato rectangular como este do Terminal, considera usar estas medidas (em pixeis) para cada dimensão de icone.

Canvas Size Base Line x-Height Mean Line Height
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

Exceções

Há excepções. Muitos icones (especialmente icones de MimeType) têm elementos ascendentes e descendentes, que são aqueles que ultrapassam a base line e a linha x-height (apresentados aqui a Laranja.)

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

Componentes arredondados necessitam normalmente de ultrapassar os limites, para compensar a ilusão de optica que os torna aparentemente menores do que os seus congéneres quadrangulares.

Outlines e contraste

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

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

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

Sombreados e luz

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

Iluminação dos vértices

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

Edge highlight example in elementary OS Music icon

Drop Shadow

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

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

Sombra do pictograma

Se o teu icone tem um pictograma, como por exemplo o triângulo do botão de play do icone seguinte, podes atribuir uma drop shadow para que sobresaia do background do icone.

Para fazeres isto, duplica o pictograma, enche-o com preto sólido, e altera a opacidade para 15%. De seguida desloca-o 1 pixel para baixo e coloca-o por debaixo do pictograma original. Cria uma cópia desta sombra é dá-lhe um stroke de 1 pixel (também preto) e ajusta este elemento para 7% de opacidade.

Icones e materiais

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

Dos e Don'ts

A seguir apresentamos ainda alguns "Dos e Don'ts" com exemplos para considerares quando criares os teus icones.

Texto

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

Estilo de Escrita

Segue as seguintes regras para manter o teu texto consistente e compreensível:

Sê Breve

Não entregues ao utilizador uma quantidade enorme de texto para ler; uma frase comprida pode desencorajar os utilizadores de a ler. Entrega sim texto curto e conciso.

Pensa Simples

Assume que o utilizador é inteligente, mas não técnico. Evita palavras compridas ou estranhas e foca-te em usar verbos simples, comuns, nomes e adjectivos. Nunca uses jargão técnico.

Vai directo ao assunto!

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

Não Te Repitas

Repetição pode ser irritante e adiciona desnecessariamente comprimento a tua mensagem.

Usa Hierarquia Visual

Hierarquia visual ajuda os utilizadores a ler e compreender o teu texto, bem como a reconhecer o que é mais importante. Usa correctamente cabeçalhos e os outros estilos.

Idioma

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

Capitalização

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

Capitalização de Frase

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

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

Capitalização de Tìtulo

Neste tipo de capitalização usa-se maiúsculas como num título de um livro ou artigo.

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

Notas/Exceções

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

Pontuação

A tipografia é importante no elementary OS. Não só por uma questão de consistência, mas para seguir as convenções próprias e apresentar ao utilizador como uma plataforma séria, profissional.

Prevenir Erros Comuns

Hyphens & Travessões

Hífen (-)

Usa \u2010 no código para:

Travessão menor (–)

Usa o \u2013 no teu código para:

Travessão Maior (—)

Usa o \u2014 no teu código para:


Em caso de dúvida, por favor espreita o Butterwick's Practical Typography.

Algumas destas regras aplicam-se apenas para a língua inglesa; existem algumas regras locais que devem ser sempre seguidas pelos tradutores.

Usando Reticências

O caracter reticências (…) é usado na interface por duas razões principais: Informar o utilizador de que há informação acessória importante, e indicar que existe texto adicional que foi encurtado.

Informação Adicional

As reticências devem ser usadas para informar um utilizador que mais informação, ou uma acção adicional serão necessárias antes de realizar a acção desejada. Normalmente isto indica ao utilizador que espere um novo elemento da interface de utilzador, como uma janela, um diálogo, barra de ferramentas, etc, na qual terão que indicar mais informação ou seleccionar antes de completar a acção pretendida. Isto é uma ideia importante pois o utilizador espera acções imediatas nos botões e menus, e assim ficam preparados para um comportamento alternativo. Mais especificamente deve ser usado quando a acção associada:

Texto Encurtado ou Truncado

Reticências devem ser usadas quando se encurta texto que não cabe num lugar específico. Por exemplo, se o nome de uma playlist for comprido demais, trunca-se e usa-se reticências para sinalizar que foi truncado. Existem duas formas para usar reticências quando se trunca texto:

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

Quando Não Usar Reticências


Certifica-te que usas o símbolo de reticências (…) e não os três pontos finais consecutivos (.).

Nomenclatura de Itens de Menu

Os items de menu devem ter nomes que são acções ou localizações, e nunca descrições. Certifica-te que os items de menu são concisos, mas que descrevem claramente a acção que será desempenhada quando clicados.

"Encontrar na página..." é aceitável já que descreve claramente uma acção que será levada a cabo quando o item é clicado. "Software Atualizável" não é aceitável. O que acontece quando carrego neste botão? o que é que vai acontecer? o resultado é incerto.