We're Crowdfunding on IndieGoGo Back Us

Directrices de interfaz humana

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

Para ayudarlo a obtener estas metas, esta guía cubrirá elementos básicos de interfaz, cómo usarlos y colocarlos juntos efectivamente, y cómo integrar bien su aplicación con el escritorio. Lo más importante es recordar que seguir esta guía hará mas fácil diseñar una aplicación, no lo contrario.

Sin embargo, tenga en mente que esto es una guía, no un reglamento. Nuevos y sorprendentes paradigmas de interacción aparecen todos los días y más aguardan a ser descubiertos. Este es un documento activo que puede y será modificado.

Para las secciones que todavía no se han escrito, consulte las Directrices de GNOME

Filosofía de diseño

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

Lo que no es el diseñ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. El diseño no es algo que se añade después de terminar un producto. Se dé cuenta o no, siempre está diseñando todo lo que construye. Es una parte intrínseca de la creación de algo. El diseño no se refiere únicamente a lo visual; no se trata solo de colores y tipos de letra. El diseño es sobre cómo funciona. Cuando decide añadir un botón que hace algo, eso es diseño. Hizo la decisión de añadir un botón con un icono o etiqueta, dónde ponerlo y el tamaño y color de ese botón. Las decisiones son diseños.

  2. El diseño no es su opinión personal. El diseño se puede poner a prueba. Hay diseños que cumplirán con un objetivo mejor que otros. Considere los distintos tipos de bicicletas. Las bicicletas plegables tienen metas de diseño diferentes de las de montaña. Aspectos como el peso, el tamaño y el dibujo del neumático son factores importantes que ayudan al usuario previsto a alcanzar sus metas. Como entendemos que el diseño se trata de solucionar problemas específicos, también debemos entender que es posible comparar objetivamente la eficacia que dos diseños tienen para solucionar esos problemas.

  1. «Diseñar no es aplicar barniz.» —Aral Balkan
  2. «El diseño no es subjetivo.» —Jeff Law

Concisión

Todo el tiempo trabaje para que su aplicación se entienda al instante. La función principal de la aplicación debe ser evidente. Existen varias maneras de lograr esto, y una de las mejores es apegarse al principio de la concisión.

Evite el exceso de funcionalidades

En muchas ocasiones es tentador añadir funcionalidades nuevas en su aplicación. Sin embargo, es importante reconocer que cada funcionalidad nueva tiene su precio. En específico, siempre que se agrega una funcionalidad más:

Pensar en módulos

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

Evite la configuración

Dentro de lo posible, evite proporcionar opciones en la aplicación. Añadir opciones es frecuentemente, una forma fácil para evitar tomar decisiones sobre el comportamiento de una aplicación. Sin embargo, igual que con el problema de exceso de funcionalidades, las opciones equivalen a más código, más errores, más pruebas, más documentación necesaria y, en general, más complejidad.

Cree una primera experiencia favorable

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.

Solicitar datos al sistema operativo

Recupere, de forma automatizada, tanta información como sea posible. En lugar de solicitar a los usuarios que proporcionen su nombre o ubicación, obtenga los datos del sistema. Esto ahorra tiempo a los usuarios y hará a su aplicación parecer inteligente e integrada.

¿En verdad lo necesita?

Pregúntese si la opción que está por añadir es en verdad necesaria o si tiene sentido para un usuario. Jamás pida que los usuarios realicen decisiones de ingeniería o diseño por sí mismos.

Cuando definitivamente tiene que hacerlo

Mantenga las opciones en su contexto. En lugar de separar las preferencias en un cuadro de configuración, piense en mostrarlas en su contexto junto a aquello que afecta (muy similar a cómo las opciones de reproducción aleatoria y repetición aparecen cerca de la biblioteca de música).

Si su aplicación necesita configuración antes de poder utilizarla (p. ej., un cliente de correo electrónico), exponga las opciones directamente en la ventana principal de forma parecida a una pantalla de bienvenida. Asegúrese de que las opciones sean absolutamente necesarias; el añadir pantallas de configuración innecesarias disuade a los usuarios de hacer aquello que querían cuando abrieron la aplicación.


Véase también:

  1. «Casillas de comprobación que acaban con su producto». —Alex Limi
  2. «No dé trabajo miserable a sus usuarios». —Zach Holman
  3. «El antipatrón de los asistentes». —Stef Walter

Un mínimo de documentación

La mayoría de los usuarios no esperan leer archivos de ayuda antes de que puedan usar su aplicación. Al contrario, esperan que esta sea intuitiva y sencilla de entender sin ayuda.

El texto debe ser fácil de entender

Evite la jerga técnica y asuma poco o ningún conocimiento técnico. Esto permitirá a su aplicación «documentarse a sí misma».

Proporcione explicaciones no técnicas en vez de mensajes de error crípticos. Si algo falla, debe aparecer una explicación simplificada de lo que ocurrió y de cómo corregirlo.


Para más información, consulte Estilo de escritura.

Flujo de trabajo del usuario

El diseño atractivo es una gran parte de la experiencia del usuario, pero también lo es el flujo de trabajo del usuario, o la forma en que interactúa con una aplicación. En esta sección, cubrimos algunos pasos importantes de un flujo de trabajo típico:

Experiencia de la primera apertura

Configuración necesaria

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.

Velocidad de apertura

Primer lanzamiento de sus aplicaciones es la primera impresión del usuario de su aplicación; es una oportunidad para mostrar realmente su diseño y la velocidad. Si su aplicación tiene que configurar las cosas en el fondo antes de ponerse en marcha de forma visible, se le da al usuario la impresión de que la aplicación es lenta o tomará mucho tiempo para poner en marcha. En su lugar, se centran en hacer que la ventana de la aplicación aparezca rápido y listo para ser utilizado, a continuación, realice las tareas de fondo detrás de las escenas. Si la tarea de fondo se está bloqueando (. Es decir, el usuario no puede realizar ciertas tareas hasta que sea completo), muestran algún tipo de indicación de que un proceso de fondo está sucediendo y crea los elementos de la interfaz de usuario bloqueado de forma insensibles (ver: Widget Concepts).

Bienvenida al usuario

Si no hay contenido para mostrar al usuario, las acciones provistas pueden actuar utilizando una simple pantalla de bienvenida. Permítales abrir un documento, añadir una cuenta, importar un CD, o cualquier cosa que tenga sentido en el contexto de la aplicación.

Restablecimiento de la aplicación

Si los usuarios «restablecen» explícitamente la aplicación (p. ej., al eliminar todas las canciones de una fonoteca o al quitar todas las cuentas en un cliente de correo), esta debe volver al estado que tenía cuando se abrió por primera vez.

Apertura normal

Cuando un usuario inicia una aplicación, está realizando una acción explícita y la espera rápido, a menudo la respuesta inmediata. Usted debe centrarse en tres áreas clave para el lanzamiento de la aplicación: la velocidad, la evidencia de qué hacer a continuación, y el estado.

Velocidad

Como se ha dicho antes, la velocidad, especialmente al iniciar una aplicación, es muy importante. Debe ser el plazo más corto posible entre el tiempo que un usuario decide lanzar una aplicación, y en el instante en que puede comenzar a utilizarlo. Si su aplicación requiere una pantalla de presentación, lo estás haciendo mal.

Obviedad

Cuando un usuario ejecute su aplicación debe saber exactamente qué hacer después. Esto se consigue siguiendo las pautas de otras interfaces (asegurándose de que su aplicación sea coherente con otras) y dando opciones específicas desde el principio. Si la aplicación muestra normalmente "elementos" como canciones o correos electrónicos, permita que el usuario pueda acceder a ellos mediante mostrarlos cuando se abra la aplicación. Si no hay elementos abiertos previamente debería dar la posibilidad de abrir o crear un nuevo elemento (como un documento) usando una pantalla de bienvenida.

Estado

Si el usuario ya ha utilizado la aplicación, generalmente es mejor restaurar el estado de la aplicación cuando se abre de nuevo. Esto significa que la aplicación inicia justo donde el usuario la dejó para que puedan tomar su trabajo de nuevo. Para un reproductor de música, esto significa que la apertura iniciara con la vista en la que el usuario la dejo y la canción en pausa cuando el usuario cerró la aplicación. Para un editor de documentos, esto significaría que la apertura sera con el mismo desplazado del documento hasta el mismo punto con el cursor en el mismo lugar en la página.

Siempre permita deshacer

A veces un usuario cumplirá una acción que podría ser destructiva o tradicionalmente irreversible. En lugar de presentar al usuario una advertencia, las aplicaciones deberían permitir al usuario bajo la acción de un apropiado período de tiempo. Algunos buenos ejemplos de cuándo es útil este comportamiento son:

Este comportamiento, sólo como último recurso, debe ser implementado proporcionando un tiempo de seguridad entre que la app muestra al usuario lo que ha pasado y lleva a cabo realmente la acción. Para mantener interactiva la experiencia, la aplicación debe aparentar siempre que ha realizado la acción en cuanto el usuario la inicie.

Este comportamiento rompe con el equilibrio perfecto de no entrometerse en las acciones del usuario pero asegurándose de que no hacen nada no intencionado. Es importante que la acción de deshacer pase desapercibida, pero que a la vez sea simple e intuitiva; una manera común de hacer esto es usando una barra de información, aunque otros métodos pueden ser apropiados.


Véase también: «No lance advertencias cuando se puede deshacer una acción». —Aza Raskin

Guardado perenne

Los usuarios deben sentirse seguros usando elementary; deben saber que todo lo que ven está guardado y actualizado.

Las aplicaciones en elementary deberían funcionar según el principio de «guardado perenne». Esto significa que las modificaciones que realicen los usuarios deben aplicarse y visualizarse instantáneamente; hacer que los usuarios guarden manualmente archivos u opciones debe ser una acción especializada u obsoleta.

Por ejemplo, un panel de información de una canción debe actualizar la información de la pista instantáneamente sin que el usuario tenga que pulsar ningún botón de guardado; los ajustes del usuario deben ser aplicados en el momento que estos se manipulan; y una app cerrada debe reabrirse justo donde el usuario la dejó.

Cierre

Cuando una usuario cierra una aplicación, normalmente es porque ha terminado de utilizarla y quiere quitársela de en medio.

Guardar el estado

Las aplicaciones deben guardar su estado actual al cerrarlas, de manera que puedan volver a abrirse justo donde el usuario las dejó. Lo ideal sería que cerrar y reabrir una aplicación fueran idénticos a los conceptos tradicionales de minimizar y maximizar una aplicación; lo que es lo mismo, que todos los elementos fueran guardados incluyendo documentos abiertos, posición en la pantalla, el historial de cambios, etc.

Tareas en segundo plano

Si para una aplicación tiene sentido completar la tarea en segundo plano despúes de que la ventana es cerrada, la tarea debería completarse tan pronto la ventana es cerrada. Si la aplicación realiza varias tareas en segundo plano (como el cliente de correo), la tareas en segundo plano deberían ser manejadas por un daemon separado que no depende de la aplicación en sí después de abierta.

Cierre de la ventana de la aplicación

No es deseable para una ventana de aplicación minimizar simplemente cuando el usuario intenta cerrarla. En cambio, la ventana de la aplicación debe estar "oculta". Si tiene sentido seguir un proceso en segundo plano (como la descarga / transferencia, escuchar música, o ejecutar un comando de terminal) la aplicación debe continuar con la tarea en segundo plano y se cierra cuando se termina la tarea. Si no es inmediatamente evidente que el proceso se ha completado (como ocurre con la descarga del archivo / transferencia o comando de terminal), la aplicación puede mostrar una notificación que informa al usuario de que el proceso se ha completado. Si es evidente, como con la música, la notificación no es necesaria.

Reapertura de la ventana de la aplicación

Si el usuario vuelve a abrir una aplicación mientras el proceso de fondo se sigue ejecutando, la aplicación debería aparecer exactamente donde estaría si la ventana hubiera estado abierta todo el tiempo. Por ejemplo, la terminal debería mostrar cualquier salida de terminal, el reproductor de música debería estar en la misma página que cuando se cerró, y el navegador debería contener la página en la que estaba anteriormente. Para más detalles, vea el debate sobre estado de aplicación en Ejecución normal.


Véase también: «Bien, terminamos». —Matthew Paul Thomas

Integración con el escritorio

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

Lanzadores de aplicaciones

El principal método de descubrimiento y uso de su app será a través de un lanzador en Slingshot o en el dock. Para proporcionar estos lanzadores, debe instalar un archivo .desktop junto con su app. Esto incluye darle a su lanzador un nombre apropiado, colocarlo en la categoría adecuada, asignarle un icono, etc.

Los archivos .desktop siguen las Especificaciones de Acceso al Escritorio -en inglés- de freedesktop.org. Deben ser instaladas en /usr/share/applications. Los usuarios pueden crear sus propios lanzadores poniendo archivos .desktop en ~/.local/share/applications.

Los contenidos de los archivos .desktop deben seguir este modelo:

Title es un GenericName que te permite Comment.

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.

GenericName

Si su app es fácilmente clasificada o descrita con un nombre genérico, debe usarlo para el atributo GenericName del archivo .desktop de su app. Si usted dice "Mi app es un(a) _____", entonces lo que vaya en ese hueco debe ser el nombre genérico. Por ejemplo, Maya es un calendario, así que su nombre genérico es "Calendario".

No incluya artículos (el, la, un, una) ni las palabras «programa» o «aplicación» en el nombre genérico de su aplicación.

En inglés, utilice el estilo de mayúsculas para títulos —norma que en español no se aplica— para el nombre genérico, que se utilizará en varios sitios del sistema operativo para describir o categorizar su aplicación.

Comment

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:

El comentario de la aplicación debe escribirse en estilo de oración, sin incluir puntuación final (punto, signo de admiración o de interrogación) y muy conciso, describiendo el caso de uso principal de la aplicación.

Categorías

Las siguientes categorías se pueden utilizar para ayudar con la búsqueda o la navegación para su aplicación:

Para más información, vea FreeDesktop.Org menu entry spec.

Palabras clave

Puede incluir palabras clave en su lanzador para facilitar a los usuarios que encuentren su aplicación a través de búsquedas. Estas siguen las convenciones de las "X-GNOME-Keywords" (para el lanzador de aplicaciones) y "X-AppInstall-Keywords" (para el instalador de aplicaciones). Por ejemplo, un navegador web podría incluir "Internet" como palabra clave aunque no forme parte del nombre de la aplicación, el nombre genérico o la descripción. Como consecuencia, si un usuario busca "Internet" encontrará la aplicación. Aquí hay algunos ejemplos más:

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


Vea también: Especificación de entrada al escritorio de 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:

Mostrar resultados de Contractor

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

Integración con el dock

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

Barras de progreso

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.

Insignias

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

Los indicadores son iconos pequeños ubicados en el panel superior. Estos permiten a los usuarios obtener información rápida sobre distintas configuraciones y sucesos. Al pulsar en uno de estos iconos aparece un menú que incluye acciones relacionadas con este y que los usuarios pueden manipular.

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 contenedores

Ventanas

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 ventanas

Cuando se trate de títulos de la ventana , considere que su uso principal es para distinguir una ventana de otro . Un buen título de la ventana proporcionará una descripción que ayuda a los usuarios a hacer una selección. Tenga esto en cuenta al considerar el siguiente

Cuadros de diálogo

24
Icono de advertencia de diálogo

Texto primario proporcionando información básica y una sugerencia

Texto secundario proporcionando detalles adicionales. También incluye información que explica cualquier consecuencia no evidente de las acciones.

24
Cancelar
Acción Sugerida

Texto de alerta

Las alertas contienen texto primario y secundario.

El texto primario contiene un breve resumen de la situación, y sugiere una acción. Este texto debería usar la clase CSS primary.

El texto secundario explica a detalle la situación y describe cualquier efecto secundario que pueda resultar como consecuencia de las acciones disponibles. Cabe mencionar que los usuarios solo deberían necesitar el texto primario para hacer una decisión; el texto secundario solo aclara las cosas. Este texto se ubica debajo del primario, separado de este por un salto de línea, y mostrado en el tamaño y peso de letra predeterminado.

Haga que los textos primario y secundario puedan seleccionarse. Esto permitirá a los usuarios copipegarlo para, por ejemplo, enviarlo en un mensaje de correo electrónico.

Orden de los botones

«Aceptar» no es adecuado

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.

Cuadros de diálogo de preferencias

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.


Véase también:

  1. «Por qué el botón “Aceptar” funciona mejor a la derecha». —UX Movement
  2. «Por qué el botón “Aceptar” no es aceptable». —UX Movement
  3. «¿Debería utilizar “Sí/No” o “Aceptar/Cancelar” en mi cuadro de diálogo?». —UX StackExchange
  4. «Dónde ubicar los iconos junto a etiquetas de botones». —UX Movement

Globos

Los globos son parecidos a los cuadros de diálogo en el sentido de que ambos muestran contenido transitorio que se relaciona directamente con un objeto que se pulsó; además, se cierran al pulsar fuera de ellos, como los menús.

Utilice globos cuando los usuarios quieran realizar una acción rápida sin perder de vista la interfaz gráfica principal. Por ejemplo, al añadir un contacto a partir de un mensaje de correo, al agregar un marcador en el navegador, o al mostrar las descargas o transferencias de archivos.

No use globos para mostrar simples listas de elementos —para eso son los menús—. Tampoco los utilice si los usuarios pasarán mucho tiempo en ellos —son mejores los cuadros de diálogo en ese caso—. Recuerde que los globos son contextuales y deben relacionarse directamente con el elemento de la IU que los genera.

Barras de herramientas

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.

Ordenar los elementos de la barra de herramientas

Los elementos de la barra de herramientas se deberían organizar con los objetos más significativos a la izquierda y los menos significativos en la derecha, con el Menú de la Aplicación siempre en el extremo derecho de la barra de herramientas. Si tienes muchos elementos en la barra de herramientas, puede ser apropiado dividirlos en grupos con espacio entre cada grupo. Ten en cuenta que cuando se ve con idiomas RTL, el diseño de la barra de herramientas se volteará.

Elementos del kit de herramientas de 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.

Conceptos de los widgets

Antes de enfatizar en todas las herramientas disponibles en elementary OS, necesitamos cubrir algunos conceptos básicos que se aplican a todas las herramientas. Emplear estos conceptos correctamente creara una experiencia mas sencilla para los usuarios y ayudara tener que recurrir a reportes de errores

Controles que no hacen nada

Un error muy común que los desarrolladores de hacer es crear controles que aparentemente no hacen nada. Tenga en cuenta que queremos dar a conocer un entorno donde los usuarios se sientan cómodos explorando. Un usuario curioso va a interactuar con un control y esperar que haya algún tipo de reacción inmediata. Cuando un control aparentemente no hace nada, esto crea confusión y puede dar miedo (Piensa, "uh-oh No sé lo que pasó!"). En algunos casos, los controles que no hacen nada son simplemente el desorden y añaden una complejidad innecesaria a su interfaz de usuario.

Considere el botón "clear" presente en en campos de búsqueda. Este botón sólo aparece cuando es pertinente y necesario. Al hacer click en este botón cuando el campo ya está vacio, esencialmente no hace nada.

Sensibilidad

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.

Por lo general es mejor desactivar un control a ocultarlo por completo. Al desactivar un control, los usuarios saben que la funcionalidad está disponible, pero solo si se cumple una condición. Al ocultar el control se da la impresión de que la funcionalidad no está disponible y puede dar lugar a que los usuarios se pregunten por qué «ha desaparecido» de repente.

Widgets ocultos

Cuando un widget sólo tiene sentido en un contexto determinado (no como un indicador de una acción a realizar) a veces no tiene más sentido para ocultarlo. Tome los requisitos de hardware, por ejemplo: Puede que no tenga sentido para mostrar las opciones de múltiples pantallas si el sistema sólo tiene una sola pantalla. Haciendo opciones de múltiples pantallas minúsculas no es realmente una sugerencia en este sistema. Otra excepción a esta regla es un widget que un usuario sólo buscará en su contexto, como el ejemplo de botón de borrado anteriormente. Por último, tenga en cuenta que los artículos minúsculas todavía serán reconocidos por los lectores de pantalla y otra tecnología de asistencia, mientras que los widgets ocultos no.

Espaciamiento

Alineación


Véase también: Proximidad de etiquetas en formularios: alineadas a la derecha son más fáciles de explorar. —UX Movement

Barras de información

Las barras de información proporcionan información contextual y acciones para el usuario con diferentes niveles de severidad.

Es importante determinar la severidad o el tipo de la barra de información a utilizar. Hay cuatro tipos de barras de información disponible:

Pantalla de bienvenida

La pantalla de bienvenida es una buena manera de ayudar a que los usuarios se familiaricen con su aplicación.

Uso

Normalmente, la pantalla de bienvenida se utiliza en aplicaciones como Noise o Scratch, en las que es necesario importar o crear objetos antes de poder interactuar con ellos. De esta manera, los usuarios saben con rapidez cómo comenzar a usar la aplicación y qué pasos hay que seguir.

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

Uso de etiquetas

La pantalla de bienvenida contiene dos conjuntos de etiquetas:

Iconografía

Cada acción incluye un icono para facilitar su visualización rápida. En la mayoría de los casos se utilizan iconos de acciones, pero también es posible utilizar iconos de lugares, para acciones como importar; e incluso iconos de aplicaciones, para abrir utilidades de configuración.

Lista de orígenes

Se pueden utilizar las listas de orígenes como navegación de nivel principal. Estas listas son útiles para mostrar ubicaciones, marcadores o categorías dentro de su aplicación.

Secciones

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.

Evite anidar secciones expandibles dentro de una lista de fuentes, si es posible; si usted desear hacer esto, es posible que tenga que replantearse las secciones.

Jerarquía

La jerarquía es importante con las listas de fuentes, tanto dentro del propio widget como dentro del ámbito más amplio de su aplicación.

Secciones en la lista de origen deben ser ordenadas por más importante en la parte superior a la menos importante en la parte inferior. Si usted está teniendo dificultades para decidir la importancia relativa de cada sección, piense en qué sección un usuario es probable que utilice con más frecuencia. Clasificación de los tramos de esta manera se asegura de que los elementos más importantes son siempre visibles, aunque la lista de fuentes es demasiado corta para encajar todos los elementos, aunque de artículos de golf en el fondo seguirá siendo accesible a través de desplazamiento.

Las listas de orígenes se colocan en el lado izquierdo de las ventanas (o el derecho si se utiliza un idioma cuya dirección de escritura es de derecha a izquierda). Debido a que los usuarios leen en esta dirección, se fortalece la noción de que la barra lateral pertenece a un nivel anterior (superior) que el contenido de la aplicación.

Botones

Es muy importante entender el funcionamiento y la utilización de los botones, ya que, sin duda, su aplicación incluirá algunos.

Botones de herramientas

Uso de etiquetas

Botones de Herramientas son casi siempre icon-only y no proporcionan una frontera botón. No deben ir acompañados de una etiqueta.

Información sobre herramientas

Todos los botones de herramientas deben tener información sobre herramientas, ya que no contienen una etiqueta. Esto ayuda a los usuarios con discapacidad, así como dar una traducción de un icono reconocido. Información sobre herramientas se deben hacer en el asunto Sentencia.

Al igual que las etiquetas de los botones de texto, los recuadros emergentes deben describir claramente lo que sucederá cuando se presione el botón.

Botones con texto

Uso de etiquetas

Las etiquetas de los botones con texto deben escribirse en inglés con el estilo de título.

Como los elementos de un menu, las etiquetas de los Botones deben consistir en una Acción o Localización pero no en un estado. Asegúrate que la etiqueta del botón describa claramente que pasa cuando los pulsas.

«Eliminar cuenta», «Transferir al portátil de José» e «Importar 20 canciones» son etiquetas adecuadas.

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

Información sobre herramientas

Como los botones de texto contienen una etiqueta clara y explícita, normalmente es innecesario añadirles un mensaje emergente.

Botones enlazados

Uso

Los botones Vinculados se utilizan para las acciones de grupo que ya sea de naturaleza similar o mutuamente excluyentes. Por ejemplo, podrían ser opciones de texto en grupo, como negrita, cursiva y subrayado. O pueden ser utilizados para agrupar estados mutuamente excluyentes como Cuadrícula, Lista o vista de columna.

Uso de etiquetas

Los botones enlazados no deben nunca contener iconos coloridos; únicamente iconos monocromáticos de 16 × 16 px o texto. No combine iconos y texto.


  1. «Por qué el botón “Aceptar” no es aceptable». —UX Movement
  2. «¿Debería utilizar “Sí/No” o “Aceptar/Cancelar” en mi cuadro de diálogo?». —UX StackExchange

AppMenu

El AppMenu es un menú opcional que se abre mediante el icono de la rueda dentada en el extremo derecho de la barra de herramientas de una aplicación. Este menú sustituye a la barra de menús tradicional y, por tanto, contiene las mismas órdenes.

Uso

Debe considerar en primer lugar si su aplicación necesita este widget. Aunque que la mayoría de las aplicaciones tengan uno, eso no significa que deba utilizarlo.

Tome en cuenta estas consideraciones antes de añadir elementos al AppMenu:

Campos de búsqueda

Las aplicaciones que soportan la búsqueda o filtrado de contenidos deben incluir un campo de búsqueda en la parte derecha de la barra de herramientas de la aplicación. Esto ofrece a los usuarios un lugar predecible para ver si, si o no una aplicación soporta la búsqueda, y una ubicación coherente que va a buscar. Gtk + proporciona un widget complejo conveniente para este propósito llamado Gtk.SearchEntry.

Distinguir entre Buscar y Encontrar

La búsqueda es para filtrar el contenido de una biblioteca, es decir, música o videos, a los elementos que coincidan. Buscar se inicia típicamente al escribir en cualquier lugar en una vista de biblioteca.

Encontrar es poner de relieve los casos coincidentes de una cadena, es decir, en un editor de texto, página web, o Terminal. Es provocada por una combinación de teclas (Ctrl+F) o con un icono de búsqueda. La barra de búsqueda aparece en un revelador por debajo de la la barra de título con las acciones pertinentes, tales como encontrar siguiente, Buscar anterior, resalte todo, etc. El revelador puede contener también otras acciones pertinentes, tales como reemplazar o ir a la línea.

Comportamiento

Siempre que sea posible, es mejor incluir la funcionalidad de búsqueda dentro su aplicación, Cualquier lista o representación de múltiples piezas de datos deberían poder ser encontradas usando un campo de búsqueda que siga estas reglas:

Uso de etiquetas

Los campos de búsqueda deben contener texto indicio de que describe lo que será la búsqueda. Puede establecer esta propiedad mediante el "placeholder_text".

La mayoría de campos de búsqueda deben utilizar el formato «Buscar OBJETOS», donde «OBJETOS» puede ser «contactos», «cuentas», etcétera.

Si el campo de búsqueda interactúa con un servicio de búsqueda, la etiqueta debe ser el nombre del servicio, como «Google» o «Yahoo!»

Casillas de verificación e interruptores

Casillas de verificación

Las casillas de verificación presentan una forma a los usuarios para seleccionar elementos de una lista.

Uso

Utilice las casillas de verificación cuando los usuarios realicen una selección de elementos. Asegúrese de que los usuarios puedan conmutar el estado de la casilla al pulsar en la etiqueta asociada a esta.

Uso de etiquetas

Las etiquetas asociadas con casillas de verificación generalmente deben ser sustantivos o frases con sustantivos.

Interruptores

Los interruptores permiten a los usuarios «encender» o «apagar» una funcionalidad o comportamiento.

Uso

No utilice switches para incluir elementos relacionados como parte de una lista, en lugar de utilizar una casilla de verificación. Piense en los switches como actuando sobre los servicios y casillas de verificación como la inclusión de objetos en una lista independiente. Esta es una distinción importante que hacer.

Observe que la opción "Grabar desde el micrófono" es un gran candidato para un interruptor. Es activar y desactivar este servicio de grabación.

Sin embargo, si hay dos opciones "sistema de de grabación de sonidos" y "Grabar desde el micrófono" que ahora están tratando con una lista de artículos relacionados para incluir como parte de un servicio de grabación más grande (que está dentro y fuera del estado es independiente de qué servicios se incluye ). En este caso, una casilla de verificación es más apropiado para referirse a esta inclusión.

Uso de etiquetas

Cuando sea posible, llame directamente el servicio que está actuando en. No utilice palabras que describen el estado que el widget está describiendo como "Habilitar Multitouch", "Uso Multitouch", o "Desactivar Multitouch". Esto puede crear una situación confusa lógicamente. En lugar de ello, basta con utilizar el sustantivo y escribir "Multitouch".


Véase también: Tres maneras de facilitar la pulsación de casillas y botones de opción. —UX Movement

Cuadernos

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

Cuaderno estático

Un Cuaderno estática es un pequeño conjunto de pestañas que no cambian, comúnmente visto en las preferencias o ajustes de las pantallas. Las pestañas aparecen como botones vinculados centrados en la parte superior del área de contenido. Un Cuaderno estático normalmente debe contener dos a cinco pestañas.

Cuaderno dinámico

Un Cuaderno dinámico es una forma de que una aplicación para proporcionar la funcionalidad de tabulación usuario manejable, comúnmente visto en los navegadores web. Las pestañas aparecen unidos a la barra de herramientas en su propia barra de pestañas encima del contenido relevante. Aquí son capaces de ser reorganizadas y cerradas y un botón de "nueva pestaña" está a la izquierda del widget notebook.

Iconografía

La iconografía es un elemento clave de elementary OS. Los iconos constituyen una gran parte de la interfaz que el usuario utiliza, le dan vida al sistema y activan el potente mecanismo de reconocimiento del cerebro humano.

Forma

Para mejorar la identificación de su icono, este debería tener una forma o silueta distintiva. Esta forma no debe ser demasiado complicada, pero el icono no debería ser siempre un rectángulo redondeado.

Icono de diálogo de advertenciaIcono de chatIcono de fotosIcono de videosIcono de cuentas en lineaIcono de terminal

Metáforas

La forma típica de los iconos para dispositivos de hardware y tipos de archivo depende de sus contrapartes del mundo real. Por ejemplo, el icono para representar una cámara se inspira en una cámara real.

Icono de cámaraIcono de disco duroIcono de ratón de computadoraIcono de paqueteIcono de texto HTMLIcono de computadora

Iconos de acción

Los iconos de acción son usados para representar acciones comunes del usuario, tal como "eliminar", "reproducir", o "guardar". Estos iconos se encuentran principalmente en las barras de herramientas de las aplicaciones, pero pueden ser encontradas en todo el sistema operativo.

Icono de previoIcono de siguienteIcono de exportar documentoIcono de impresiónIcono de guardarIcono de borrarIcono de cortarIcono de revertirIcono de invertirIcono de reproducciónIcono de etiqueta nuevaIcono de menú

Si su aplicación hace uso de una de estas acciones comunes, referencia en su icono correspondiente en lugar de crear el suyo propio. Esto asegura una experiencia de usuario consistente y ayuda en el reconocimiento del usuario de funciones comunes.

Si su aplicación tiene una acción única, es posible que deba crear una propio. Al hacer esto, trate de seguir el aspecto de los iconos de acción existentes, e incluir junto con su aplicación.

Tamaños de iconos

elementary OS usa seis principales tamaños de icono en todo el sistema operativo y lo mejor es incluir los seis como parte de su aplicación.

Icono de Terminal de 16 pixelesIcono de Terminal de 24 pixelesIcono de Terminal de 32 pixelesIcono de Terminal de 48 pixelesIcono de Terminal de 64 pixelesIcono de Terminal de 128 pixeles
16 24 32 48 64 128
Icono de Terminal de 128 pixeles
128

Diseña cada icono para el tamaño para el que será visto. En otras palabras, no diseñes un icono y lo redimensiones para cubrir el resto de los tamaños, el mejor resultado se obtiene cuando cada icono se diseña individualmente. Para más información acerca de esta práctica (llamada "pixel-fitting") y su importancia, recomendamos leer el artículo de Dustin Curtis Pixel-fitting.

Gama de colores

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.

Icono de correoIcono de lector RSSIcono de navegador webIcono de fotosIcono de redIcono de calendario

Los colores tienen sus propias connotaciones, así que sé consciente de ello cuando a la hora de seleccionarles. Por ejemplo, el rojo es usualmente asociado a errores o "peligro" y el naranja a advertencias. Pero puedes usar estas connotaciones cromáticas para ayudar a transmitir significado en tus iconos, tal como el verde implica "adelante".

Iconos Simbólicos

Los Iconos Simbólicos son iconos comunes del sistema, que simbolizan archivos, dispositivos o directorios, y también se utilizan para representar acciones comunes, como cortar, copiar y guardar.

Cada icono simbólico es una forma reducida de su contraparte de colores. Este diseño minimalista garantiza lectura y claridad incluso en tamaños pequeños.

Icono Simbólico vs. de colores

Iconos de colores vs. Simbólico

El uso de iconos de colores y simbólicos no es intercambiable, ambos tienen usos apropiados.

Los Iconos de colores se usan mejor para:

Los Iconos Simbólicos se usan mejor para:

Composición

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

Mantener estas líneas en cuenta al diseñar , significa que usted puede colocar elementos a lo largo de ellos para iconos aparecen más consistente cuando se ponen juntos . Por ejemplo , observe cómo algunos elementos , tanto en el icono Terminal y Videos anteriormente se refieren a la línea media

Medidas comunes

Si usted está diseñando un icono en forma de cuadrado, como el de la Terminal se ha visto, y luego considerar el uso de estas mediciones comunes (en píxeles) para cada icono.

Tamaño del lienzo Línea de base Altura de x Línea de altura media
16 × 16 1 14 8
24 × 24 2 20 12
32 × 32 2 26 16
48 × 48 3 40 24
64 × 64 4 56 32
128 × 128 9 104 64

Excepciones

Sin embargo, hay excepciones. Muchos iconos (especialmente los iconos Mimetype) tienen ascendentes y descendentes elementos, que son los elementos que van más allá de la línea de base y línea x altura (que se muestra aquí en Naranja.)

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

Componentes más redondos generalmente requieren algún exceso, para compensar la ilusión óptica que hace que se vean más pequeños que sus contrapartes rectangulares.

Contornos y 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 Ejemplo de contraste en el icono de configuración de elementary

Para mejorar aún más el contraste, los trazos son también semitransparente. Esto asegura que los iconos aparecen nítidos contra una variedad de fondos. Además, si el elemento es casi blanco, Este movimiento actúa como un borde y contiene, en lugar de superposiciones, su elemento correspondiente. Ver el icono de arriba para un ejemplo de esto.

Sombras y resaltes

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.

Resalte del borde

Para aplicar el efecto más destacado borde a su icono, dibujar un sutil, 1 pixel , trazo interior como un punto culminante. Este esquema es ligeramente más brillante en la parte superior y la parte inferior de lo que es en los bordes.

Edge highlight example in elementary OS Music icon

Sombra paralela

Para dibujar la sombra, usted comenzará a dibujar un rectángulo. Luego lo rellenamos con un gradiente lineal que es perpendicular a la margen inferior del icono. El gradiente tiene tres escalas la primera y la última de las cuales tienen cero opacidad. Entonces toda esta forma se establece en 60% de opacidad .

A continuación crear dos rectángulos más pequeños a "sujetalibros" la de mayor tamaño. Llenar cada uno con un gradiente idéntica a la primera, pero que sea radial en su lugar. Centre el degradado radial en medio de un borde corto con cada parada directamente a la más cercana borde véase más abajo para ver un ejemplo. Estos dos rectángulos también están listos para 60% de opacidad .

Sombra del pictograma

Si el icono tiene un pictograma, como el triángulo de play en el icono de abajo, puede dar una sombra para hacer que destaque sobre el fondo del icono.

Para ello, primero duplicar el pictograma, llenarlo con negro sólido y ponerlo a 15% de opacidad . A continuación, desplazarlo 1 píxel hacia abajo y colóquela debajo del pictograma. Crear una copia de esta sombra y darle un golpe 1 píxel (también negro) y ajustar este elemento a 7% de opacidad .

Materiales de los iconos

Usted es libre de añadir brillo (puntos destacados adicionales) a su icono, pero esto es sólo una buena idea si usted está emulando una superficie que es más reflexivo en la vida real (como plástico, vidrio, etc.) Por ejemplo, una hoja de papel no es brillante, por tanto, un icono de la emulación de papel no deberia serlo tampoco.

Recomendaciones

A continuación se presentan algunas cosas que debe y que no debe hacer al crear iconos para su aplicación.

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 escritura

Siga las reglas presentadas a continuación para mantener el texto comprensible y coherente:

Sea breve

No dé demasiado texto a los usuarios: los párrafos grandes desaniman la lectura. Escriba textos concisos y breves.

Piense con sencillez

Asuma que los usuarios son inteligentes pero no técnicos. Evite palabras largas y raras; en cambio, emplee verbos, sustantivos y adjetivos sencillos y comunes. Jamás use la jerga técnica.

Vaya al grano

Coloque la información más importante al principio. Así, si los usuarios no terminan de leer, tendrán en mente los datos necesarios.

No se repita

La repetición es molesta y alarga innecesariamente los mensajes.

Utilice una jerarquía visual

La jerarquía visual ayuda a los usuarios a leer y entender el texto y, al mismo tiempo, saber qué es lo más importante. Utilice los encabezamientos y otros estilos de texto adecuadamente.

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:

Uso de mayúsculas

En inglés, todos los componentes textuales de una interfaz de usuario, incluyendo las etiquetas, los botones y los menús, deben utilizar uno de dos estilos de uso de mayúsculas: «oración» (Sentence case) y «título» (Estilo de título). Es muy importante hacer énfasis que esto solo aplica al texto que escriba en inglés; en español no existen estos estilos y no deben calcarse.

Estilo de oración

El «estilo de oración» significa que las mayúsculas se utilizan como es normal en cualquier oración o frase.

Solo se escribe en mayúsculas la primera letra de la oración y la primera letra de los nombres propios. Este estilo se utiliza en las etiquetas y los bloques de texto descriptivo.

Estilo de título

El «estilo de título» es como se acostumbra escribir el título de canciones, libros y artículos en inglés.

Las palabras primera y última llevan mayúscula inicial. También la llevan todos los sustantivos, pronombres, adjetivos, adverbios y conjunciones subordinadas (as, because, although). Este estilo se usa en títulos, botones, menús y muchos otros widgets.

Notas y excepciones

Los nombres propios siempre deben seguir el uso de mayúsculas oficial para cada cual. Esto significa que Google siempre debe escribirse «Google», elementary siempre debe mostrarse como «elementary», eBay siempre debe ser «eBay» y MPEG, un acrónimo, debe aparecer como «MPEG».

Puntuación

Es importante utilizar correctamente la ortotipografía en todo elementary OS. No únicamente por coherencia, sino también para presentarnos como una plataforma seria y profesional.

Evite errores comunes

Guiones y rayas

Guion (-)

Utilice \u2010 en el código. Este símbolo se usa para:

Semirraya (–)

Utilice \u2013 en el código. Este símbolo se usa para:

Raya (—)

Utilice \u2014 en el código. Este símbolo se usa para:


En caso de dudas, consulte Practical Typography, de Matthew Butterick.

Las reglas anteriores aplican al idioma inglés. Cada lengua utiliza sus propias normas que los traductores deberán seguir.

Uso de puntos suspensivos

Los puntos suspensivos (…) se utilizan en la interfaz de usuario por dos motivos: informar al usuario de que se necesita información adicional e indicar que se ha abreviado el texto.

Información adicional

Los puntos suspensivos se debe utilizar para permitir que un usuario que se requiere más información o una acción adicional antes de que pueda llevar a cabo su acción. Por lo general, esto significa que el usuario debe esperar un nuevo elemento de la interfaz que aparezca como una ventana nueva, de diálogo, barra de herramientas, etc en las que deben introducir más información o hacer una selección antes de completar la acción prevista. Esta es una distinción importante porque un usuario normalmente debe esperar una acción inmediata de botones y elementos de menú mientras que esto los prepara para un comportamiento alternativo. Más específicamente, una elipsis debe utilizarse cuando la acción asociada:

Texto acortado

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:

Si no está seguro, lo mejor es utilizar el truncamiento intermedio, ya que mantiene el principio y final de la cadena intacta. También es importante que usted no envíe su aplicación con cualquier texto truncado; El truncamiento sólo debe ser el resultado de una acción del usuario, como cambiar el tamaño de una barra lateral o introducir texto personalizado.

Cuándo no usar los puntos suspensivos


Asegúrese de que utiliza el carácter de los puntos suspensivos real (…) y no tres puntos consecutivos (.)

Nombrar elementos de menú

Los elementos de menú deben tener nombres ya sea acciones o lugares, nunca descripciones. Asegúrese de que los elementos de menú son concisos, pero también describen plenamente la acción que se realiza cuando se hace clic.

«Buscar en la página…» es un nombre aceptable porque describe la acción que se realizará cuando se pulse en el elemento. «Programa actualizado» no es aceptable. ¿Qué sucederá cuando se pulse en el elemento? ¿Adónde llevará? ¿Qué hará? El resultado no es obvio.