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.

Build for the "Out of The Box" Experience

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.

Avoid technical jargon and assume little-to-no technical knowledge. This lets your app be "self-documenting."

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

If a user explicitly "resets" the app (ex. by deleting all songs in a music library or removing all mail accounts in a mail client), it should return to its first-launch state.

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

When a user launches your app, they should know exactly what to do next. This is achieved by following the other interface guidelines (ensuring your app is consistent with other apps) and by offering up explicit actions from the get go. If the app typically displays "items," such as songs or emails, let the user get at those items by displaying them when the app opens. If there are no previously-opened items, you should offer to open or create a new item (such as a document) by using a welcome screen.

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

Users should feel confident when using elementary OS; they should know that everything they see is saved and up to date.

Apps in elementary OS should operate around an always-saved state. This means that changes the user makes are instantly applied and visible and that making the user manually save things is a legacy or specialized behavior.

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

It is not desirable for an app window to simply minimize rather than close when the user attempts to close it. Instead, the app window should be "hidden". If it makes sense to continue a process in the background (such as downloading/transferring, playing music, or executing a terminal command) the app backend should continue with the task and close when the task is finished. If it's not immediately apparent that the process has completed (as with the file download/transfer or terminal command), the app may show a notification informing the user that the process has completed. If it is apparent, as with the music, no notification is necessary.

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

You should not include descriptive words in your title. For example, Dexter is called "Dexter," not "Dexter Address Book." Midori is just "Midori," not "Midori Web Browser." Instead, use the GenericName attribute of your app's .desktop file for a generic name, and the Comment attribute for a longer descriptive phrase.

NomeGenérico

If your app is easily categorized or described with a generic name, you should use that for the GenericName attribute in your app's .desktop file. If you can say, "My app is a(n) ____," then whatever fits in that blank could be the generic name. For example, Maya is a calendar, so its generic name is "Calendar."

You should not include articles (the, a, an) or the words "program," "app," or "application" in your app's generic name.

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

You may also include keywords in your launcher to help users find your app via search. These follow the convention of "X-GNOME-Keywords" (for in the app launcher) and "X-AppInstall-Keywords" (for in the app installer). For example, web browser might include "Internet" as a keyword even though it's not in the app's name, generic name, or description. As a result, a user searching for "Internet" will find the app. Here are some more examples:

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

Windows form the foundation of your app. They provide a canvas with basic, built-in actions such as "closing" and "resizing". Although users may see windows as being all the same, elementary OS has several distinct window types. It's important to understand the types of windows available to you, window behavior in general, and behavior that is specific to a certain window type. This section will cover the different types of windows available in elementary OS. Although each type of window is a bit different, think of them all as a subclass of a window. Unless otherwise stated, they all behave as an average window.

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" is not Okay

When presenting a dialog to a user, always use explicit action names like "Save..." or "Shut Down". Consider how "OK" lets users proceed without understanding the action they are authorizing. Not all users will read the question or information presented to them in a dialog. Using specific action names will make it harder for a user to select an unintended action and may even encourage them to read the presented information before making a selection.

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

A very common mistake for developers to make is creating controls that seemingly do nothing. Keep in mind that we want to present an environment where users feel comfortable exploring. A curious user will interact with a control expecting there to be some immediate reaction. When a control seemingly does nothing, this creates confusion and can be scary (Think,  "uh-oh I don't know what happened!"). In some cases, controls that do nothing are simply clutter and add unnecessary complexity to your UI.

Consider the "clear" button present in search fields. This button only appears when it is relevant and needed. Clicking this button when the field is already clear essentially does nothing. 

Sensibilidade

Sometimes it doesn't make sense for a user to interact with a widget until some pre-requisite is fulfilled. For example, It doesn't make sense to let a user click a browser's "Forward" button unless there is forward history available. In this case, you should make the "Forward" button insensitive or a user may click it, expecting a result, and be confused when nothing happens.

It's usually better to make a widget insensitive than to hide it altogether. Making a widget insensitive informs the user that the functionality is available, but only after a certain condition is met. Hiding the widget gives the impression that the functionality is not available at all or can leave a user wondering why a feature has suddenly "disappeared".

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.

"Remove Account", "Transfer to Jim's Laptop", and "Import 20 Songs" are good labels.

"OK", "Get more storage!", and "Low Battery" are not good button labels. The "Get more storage!" label has incorrect capitalization and unnecessary punctuation. The other two labels do not indicate what will happen as a result of clicking the button.

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

The AppMenu is an optional menu which is opened using the gear-shaped icon on the far-right of an app's toolbar. It provides relevant menu items in place of the traditional "File, Edit, View..." menu bar.

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

Search fields should contain hint text that describes what will be search. You can set this using the entry property "placeholder_text".

Most search fields should use the format "Search OBJECTS" where OBJECTS is something to be searched, like Contacts, Accounts, etc.

If the search field interacts with a search service, the hint text should be the name of that service such as "Google" or "Yahoo!"

Checkboxes & Switches

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

Switches present a way for users to toggle certain features or behaviors "on" or "off".

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.

Notice that the option "Record from microphone" is a great candidate for a switch. You are enabling and disabling this recording service.

However, if there are two options "Record system sounds" and "Record from microphone" you are now dealing with a list of related items to include as part of a larger recording service (who's on and off state is independent of what services it includes). In this case, a checkbox is more appropriate to denote this inclusion.

Etiquetagem

When possible, directly call out the service you are acting on. Do not use words that describe the state that the widget is describing like "Enable Multitouch", "Use Multitouch", or "Disable Multitouch". This can create a confusing situation logically. Instead, simply use the noun and write "Multitouch".


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

Livro de Notas

Notebooks are a type of widget that lets apps show one of multiple pages (also colloquially referenced as "tab bars").

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

A Dynamic Notebook is a way for an app to provide user-managable tabbing functionality, commonly seen in web browsers. The tabs appear attached to the toolbar on their own tab bar above the relevant content. Tabs are able to be rearranged and closed and a "new tab" button is at the left ot the notebook 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.

Action icons are used to represent common user actions, such as "delete", "play", or "save". These icons are mostly found in app toolbars, but can be found throughout the OS.

Í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

Design each icon for the size it's meant to be viewed at. In other words, do not design one icon and resize it to fill the remaining sizes, the best result is when each icon is designed individually. For more information about this practice (called "pixel-fitting") and its importance, we recommend reading Dustin Curtis' article, 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

Colors do have their connotations, so be cognisant of this when picking them. For instance: red is usually associated with error or "danger" and orange with warnings. But you can use these color connotations to help convey your icon's meaning, such as green for "go".

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 & Contrast

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.

Shadows & Highlights

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.

Next create two smaller rectangles to "bookend" the larger. Fill each with a gradient identical to the first, but make it radial instead. Center the radial gradient in the middle of a short edge with each stop directly out to the nearest edge—see below for an example. Both these rectangles are also set to 60% opacity.

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

Below are some "do and don't" examples to consider when creating icons for your app.

Texto

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

Estilo de Escrita

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

Proper nouns should always be capitalized properly; this means that, for example, Google should always be shown as "Google," elementary should always be shown as "elementary," and MPEG should always be shown as "MPEG." If you're unsure how a certain pronoun should be officially capitalized, refer to the documentation of the pronoun in question.

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 & Dashes

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.

"Find in Page..." is acceptable as it clearly describes the action that will be performed when the item is clicked. "Software Up to Date" is not acceptable. What happens if I click this item? Where will it take me? What will it do? The outcome is uncertain.