Iconos de estado y GNOME

Iconos de estado y GNOME

Bastián
Traducción libre al español del artículo "Status icons and GNOME" escrito por Allan Day el 31-agosto-2017.

"Iconos de estado" o con algunos nombres diferentes. Mucha gente los conoce por el lugar donde aparecen, que se describe como la "bandeja de sistema" o "área de notificación". Independientemente de cómo lo llames, es el lugar donde a menudo se muestra una cadena de iconos pequeños, típicamente de aplicaciones que se ejecutan en segundo plano.

GNOME 3 muestra actualmente iconos de estado en la esquina inferior izquierda de la pantalla, en una bandeja que se contrae y se expande. Sabemos que esto no es una buena solución. La bandeja se interpone en el camino -de otras ventanas- y generalmente se siente bastante incómodo. Existe un consenso general de que no queremos continuar con esta interfaz de usuario para la próxima versión de GNOME 3.

Al mismo tiempo, el proyecto GNOME ha hecho mucho trabajo en los últimos años al reducir la importancia de los iconos de estado. Esto incluye la integración de controles multimedia e información meteorológica en el calendario de la shell, la creación de Night Light y el trabajo con desarrolladores de aplicaciones de terceros para reducir su dependencia de los iconos de estado. En la próxima versión, introduciremos una nueva API de integración para aplicaciones de sincronización de archivos, que será otro paso hacia adelante.

Desde GNOME 3.26, por lo tanto, estamos planeando no mostrar los iconos de estado en GNOME Shell por defecto. Creemos que, a largo plazo, este cambio nos permitirá ofrecer una mejor experiencia a nuestros usuarios (yo entraré en detalles al respecto en el resto del post). También sentimos que las consecuencias del cambio no serán tan dramáticas como lo habrían sido en el pasado.

Reconocemos que la gente está usando los iconos de estado hoy en día y que algunos seguirán queriendo usarlos. Eso está absolutamente bien, y nuestra decisión de dejar de mostrar los iconos de estado por defecto no es en modo alguno un juicio negativo sobre esto. Si desea o necesita seguir usando los iconos de estado, no dude en usar la extensión de GNOME shell TopIcons. Esto continuará funcionando y la extensión ofrece una mejor experiencia para los iconos estado que la predeterminada.

Por supuesto, seguiremos vigilando la situación y escucharemos los comentarios de los usuarios. También hay un conjunto completo de información sobre el cambio en la wiki de GNOME, incluyendo un FAQ y directrices para los desarrolladores de aplicaciones.

Consejos para desarrolladores de aplicaciones

Después de haber revisado cómo las aplicaciones están usando los iconos de estado, estamos seguros de que la mayoría de las aplicaciones que usan los iconos de estado no se verán afectadas por la decisión de no mostrar estos por defecto. En muchos casos las aplicaciones no tendrán que hacer ningún cambio y si los cambios son necesarios, esperamos haber contactado con usted.

También vale la pena señalar que muchas de las recomendaciones sobre cómo proporcionar una buena experiencia sin iconos de estado son guías establecidas de todos modos y pueden ser adoptadas ya sea que una aplicación esté usando un icono de estado o no (tal como usar las APIs existentes de manera efectiva y tener un comportamiento consistente cuando su aplicación es ejecutada). ¡Esta es una gran oportunidad para mejorar las aplicaciones en general!.

Si usted es un desarrollador de aplicaciones y tiene dudas acerca de si este cambio le afecta o cómo adaptarse a él, consulte las directrices en la wiki de GNOME y siéntase libre de ponerse en contacto con nosotros si aún tiene dudas. Queremos ayudarle en todo lo que podamos.

El resto de este post incluye información de fondo sobre nuestro enfoque de los iconos de estado. Esperemos que ayude a aquellos que estén interesados a entender la decisión un poco mejor.

El por qué.

¿Todavía conmigo? ¡Bien, continuemos!

Como punto de partida, vale la pena señalar que los iconos de estado son bastante antiguos. La primera versión de la especificación está fechada en abril de 2002, lo que significa que es anterior a GNOME 2.0. Tenían "mensajes de burbuja". Tal vez no hace falta decirlo, pero los iconos de estado son algo que heredamos, más que algo que fue diseñado como parte de la experiencia global -de GNOME-.

¿Pero por qué no los queremos más? Hay algunos temas específicos con los iconos de estado, a los que me referiré, pero las principales razones se relacionan con a) la existencia de mejores APIs y b) cómo se alinean con la filosofía y objetivos de diseño más amplios de GNOME. Algunos de ellos son los siguientes.

1. API específico

En GNOME tenemos dos objetivos estrechamente relacionados: proporcionar a los desarrolladores de aplicaciones una visión clara de cómo deben construirse las aplicaciones y proporcionar a los usuarios una experiencia sencilla, fácil de entender y lógica. Un ingrediente clave para lograr esto es tener un conjunto sencillo de APIs para la integración de aplicaciones -con el escritorio-.

Queremos tener APIs claramente diferenciadas, con cada una de ellas teniendo su propia función. Los ejemplos principales incluyen:

Los iconos de estado se originaron antes de todos estos y se superponen con tres de los cuatro anteriormente descritos. Esto crea ambigüedad para los desarrolladores y dificulta saber qué APIs utilizar. ¿Debería utilizar notificaciones para notificar a los usuarios o iconos de estado? ¿Es mejor utilizar un icono de estado o MPRIS para los controles multimedia? Si bien algunas de estas preguntas pueden ser respondidas mediante documentación y directrices, no se puede evitar el hecho de que generan ambigüedad e, inevitablemente, un comportamiento de aplicación inconsistente. Muchas aplicaciones utilizan hoy en día iconos de estado como un sistema de notificaciones, a pesar de la existencia de la API de notificaciones oficial, por ejemplo.

2. Aplicación versus sistema

Uno de los principios centrales de diseño de GNOME 3 es diferenciar claramente el sistema y las aplicaciones. Con ello se pretende que la estructura de la experiencia quede clara para los usuarios. Es una de las razones por las que llamamos al área en la parte superior derecha, el área de estado del sistema.

Los iconos de estado y el estado del sistema están relacionados con el estado y, por lo tanto, existe una atracción natural para fusionar los dos (de hecho, en los días de GNOME 2, los iconos de estado se utilizaron tanto para el estado de la aplicación como para el del sistema). Así es como los iconos de estado se presentan normalmente en otras plataformas. Sin embargo, creemos que esto diluiría la experiencia en su conjunto, ya que introduciría una falta de claridad sobre lo que pertenece a qué. La influencia de este tipo de distinción es sutil pero dominante.

3. Control del usuario

Otro principio de diseño clave para GNOME es poner al usuario en control. Nuestro objetivo es asegurarnos de que la apariencia y el comportamiento del sistema sean determinados por el usuario. La única persona que debería poder cambiar su fondo de pantalla, sus redes wi-fi preferidas, sus aplicaciones favoritas o su cliente de correo electrónico predeterminado, es usted. Esta es una de las razones por las que estamos tan interesados en el concepto de aplicación de espacio aislado (sandboxing).

El diseño de los iconos de estado va en contra de este principio. Sabemos por observación que a la gente a menudo sólo le importa una pequeña fracción de los iconos de estado a los que están expuestos, y el resto no refleja sus intereses o actividades. Esto se debe al icono de estado API y al ethos (costumbre y conducta) que hay detrás de él.

Los usuarios no optan por los iconos de estado. No se apartan claramente del camino cuando no se les busca (como en el caso de las notificaciones). No reflejan un tipo particular de actividad de usuario (como la integración MPRIS). En esencia, toman el control del usuario.

4. Objetivos de clics accesibles

Por último, a lo largo de GNOME 3, hemos intentado asegurarnos de que los objetivos de clic sean siempre fáciles de dirigir. Los diminutos y pequeños objetivos de clic suponen un reto en un gran número de situaciones, desde aquellos con dispositivos de señalización de baja calidad, hasta aquellos que no tienen el mismo nivel de control motor que otros. Mire a su alrededor y no verá muchos pequeños objetivos de clic en GNOME 3, y este es el motivo.

Esta meta fue una de las motivaciones para el área de estado del sistema combinado que presentamos en GNOME 3.10. Es por eso que elementos independientes en el panel superior que hemos retenido se han hecho un poco más amplios, con la adición de indicadores triangulares.

Los iconos de estado son, en esencia, una cadena de pequeños y diminutos objetivos de clic. Son difíciles de hacer clic.

Escalabilidad

Una API claramente diferenciada, una distinción entre aplicaciones y sistema, asegurar el control del usuario y manteniendo nuestra interfaz de usuario accesible son cuatro principios de diseño que forman nuestra visión sobre los iconos de estado.

Otra razón para querer alejarse de los iconos de stado es más bien una crítica al concepto mismo. Parte de la dificultad con los iconos de estado es lo atractivos que son para los autores de aplicaciones. Son visualmente prominentes, dando gran presencia publicitaria y de marca. También proporcionan a los usuarios un acceso rápido a los controles de las aplicaciones. ¿Qué es lo que no te gusta?.

Desafortunadamente, el atractivo de los iconos de estado lleva a problemas. Lo más obvio es que los usuarios a menudo terminan con demasiadas de ellas.

Cada plataforma que ha abrazado iconos de estado ha terminado teniendo que luchar con este problema, desde el desbordamiento del área de notificación de Windows, la fusión de indicadores de aplicación en Ubuntu, y una gran cantidad de modificaciones en Mac. En mi opinión, todas estas soluciones de gestión son indicativas de un problema subyacente.

Hay una contradicción en el corazón de un sistema que, por un lado, ofrece presentar la interfaz de usuario de aplicación de manera persistente, pero que puede ser utilizado por cualquier número de aplicaciones. Al final, terminas presentando más información de la que los usuarios pueden procesar. Cuando esto sucede, algunos de los iconos tienen que ser ocultados, lo que significa volver a la promesa central de presencia persistente. Todo el concepto finalmente se derrumba.

Conclusión

Reconocemos que se trata de una cuestión potencialmente controvertida. Al mismo tiempo, esperamos que este post haya contribuido a comprender mejor por qué se ha tomado la decisión y demuestre cómo forma parte de un esfuerzo más general por mejorar la plataforma.

Mi sensación es que hemos estado utilizando iconos de estado como muleta durante demasiado tiempo - que se han utilizado para llenar vacíos en nuestras APIs, vacíos que afortunadamente se están llenando - y que alejarnos de ellos nos ayudará a extender la integración de aplicaciones en algunas direcciones emocionantes.

Por último, cuando decimos que queremos escuchar la retroalimentación, realmente lo decimos en serio: hay cuestiones que es necesario abordar y de las que tenemos que enterarnos. Cuanta más información tengamos, mejor.