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 Desig

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 Balka
  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 Holma
  3. The Wizard Anti-Pattern por Stef Walte

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 Utilizado

If there is no content to show the user, provide actions they can act upon by using a simple welcome screen. Let them open a document, add an account, import a CD, or whatever makes sense in the context of the 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.

Always Provide an Undo

Sometimes a user will perform an action which could possibly be destructive or traditionally irreversible. Rather than present the user with a warning, apps should let the user undo the action for an appropriate amount of time. Some prime examples of when this behavior is useful are:

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 Raski

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 Fecha

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

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

The system uses an app's Comment attribute (found in the .desktop file) to succinctly inform a user what can be done with the app. It should be a short sentence or phrase beginning with a verb and containing the primary nouns that your app deals with. For example, the following are appropriate comments:

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

The following categories may be used to aid with searching or browsing for your app. Keep in mind that you can add more than one and you should add all that apply:

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:

Keywords should be single words (in title case) separated by semicolons.


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

Contractor

Contractor is a service and a protocol for exposing services easily between apps. It lets apps interact with other apps and services without hardcoded support for them. You simply add Contractor support, and then any service registered with Contractor is now available for your app to use. Your app can integrate with Contractor in two different ways:

Apresentar resultados do Contracto

Contractor results are typically presented to users in menu form. Keep the following in mind when presenting Contractor results:

Integração no Dock

Integrate your app with Pantheon's dock communicate to communicate its status to the user at a glance.

arrasdeprogresso

Make progress bars unambiguous by referring to a single, specific task. For example, use progress bars to indicate the status of lengthy processes like file transfers and encoding. Do not use progress bars to compound the progress of different types of action.

Crachás

A badge shows a count of actionable items managed by your app. Its purpose is to inform the user that there are items that require user attention or action without being obtrusive. This is a passive notification. A badge should not show totals or rarely changing counters. If the badge is not easily dismissed when the user views your app, it is likely that this is not a good use of a badge.

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.

Does Your App Need an Indicator?

The indicator area is prone to clutter and inconsistent paradigms. Given that users will probably install many third-party apps, we must be careful about the number of indicators we show and how they behave. Keep in mind that only a very small set of applications need or benefit from an indicator. Avoid adding an indicator if:


See also: Farewell to the Notification Area by 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
Dialog warning icon

Primary text providing basic information and a suggestion

Secondary text providing further details. Also includes information that explains any unobvious consequences of actions.

24
Cancela
Suggested Action

Texto de Alerta

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

The primary text contains a brief summary of the situation and offer a suggested action. This text should use the CSS class 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

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

Preference dialogs should be made Transient, but not Modal. When a user makes a change in a preference dialog, the change should be immediately visible in the UI. If the dialog is modal, the user may be blocked from seeing (and especially from interacting with) the change. This means they will have to close the dialog, evaluate the change, then possibly re-open the dialog. By making the dialog transient, we keep the dialog on top for easy access, but we also let the user evaluate and possibly revert the change without having to close and re-open the preference dialog.


Ver também:

  1. Why 'Ok' Buttons In Dialog Boxes Work Best On The Right por UX Moveme
  2. Why The Ok Button Is No Longer Okay por UX Moveme
  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 Moveme

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.

arra de Ferramentas

A Toolbar is useful for providing users with quick access to an app's most used features. Besides Buttons, a Toolbar is one of the most frequently used UI elements. It may seem like a simple container, but it is important to remain consistent in its use and organization.

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 Widge

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.

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.

É 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 Moveme

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

If your app lets users clear its library, make sure that it returns to the Welcome Screen instead of an empty list.

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

A source list may be separated into different collapsible sections, each with its own heading. For example, a file manager might have a section for bookmarked locations, a section for storage devices attached to the computer, and a section for network locations. These sections help group related items in the source list and lets the user hide away sections they might not use.

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.

otões

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

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

otõ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", "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.

otões Interligados

Utilização

otõ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 Moveme
  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

Apps that support the searching or filtering of content should include a search field on the right side of the app's toolbar. This gives users a predictable place to see whether or not an app supports searching, and a consistent location from which to search. Gtk+ provides a convenient complex widget for this purpose called Gtk.SearchEntry.

Distinguish Between Search and Find

Search is for filtering the contents of a library, i.e. Music or Videos, to the matching items. Search is typically initiated when typing anywhere in a library view.

Find is for highlighting matching instances of a string, i.e. in a text editor, web page, or Terminal. It is triggered by a keyboard shortcut (Ctrl+F) or with a search icon. The find bar appears in a revealer below the headerbar with relevant actions such as find next, find previous, highlight all, etc. The revealer may also contain other relevant actions such as replace or go to line.

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 Moveme

Livro de Notas

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

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

loco 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 Computado

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 RetrocedeÍcone AvançaÍcone de Exportar DocumentoÍcone de ImprimiÍcone de GravaÍcone de ApagaÍcone de CortaÍcone de desfazeÍcone de InverteÍcone de ReproduziÍ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.

Symbolic Icons

Symbolic icons are common system icons, that symbolize files, devices, or directories and are also used to represent common actions like cut, copy, and save.

Each symbolic icon is a reduced form of its full-color counter part. This minimal design ensures readability and clarity even at small sizes.

Symbolic vs. colored icon

Colored vs. Symbolic Icons

The use of full-color and symbolic icons is not interchangeable, both have appropriate uses.

Full color icons are best used for:

Symbolic icons are best used:

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.

Using Ellipses

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

Ellipses should be used when shortening text that cannot fit in any specific place. For example, if a playlist's name is longer than the space available in the sidebar, truncate it and use an ellipsis to signify its truncation. There are two ways to use an ellipsis when shortening text:

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.