viernes, 11 de diciembre de 2015

Sobre la GUI de ZinjaI

Siempre digo que ZinjaI está pensado para dos tipos de usuarios muy diferentes: para el alumno que recién empieza y necesita algo simple; y para el programador avanzado que desarrolla un proyecto de tamaño considerable y necesita algo potente. Estos dos objetivos son a todas luces contradictorios e incompatibles entre sí... ¿o no? ¿Cómo es que sigo sosteniendo semejante contradicción? ¿cuál es la estrategia para justificarlo? He aquí algunos criterios y tips sobre porqué es cómo es, y cómo ajustarlo a gustos particulares.

Para empezar, la organización de la interfaz de ZinjaI es totalmente clásica.  Arcaica dirán algunos. Si algo funciona muy bien, a mi no me gusta cambiar por el solo hecho de cambiar, mejor dedicar ese tiempo a otra cosa. La interfaz se basa en una parte central con las pestañas de código (es lo más importante, y por lo tanto ocupa el máximo espacio posible), una barra de menúes (bastante sobrepoblados) y una barra de herramientas muy clásica en la parte superior (nada de ribbons ni otros elementos "fancy"), y unos cuantos paneles acoplables que aparecen abajo y a los costados cuando se los requiere.

¿Cómo pretende esto ser simple y amigable para el usuario que llega por primera vez? Pues bien, justamente presentando una interfaz sin sobresaltos ni elementos raros que aprender, y medianamente limpia. En este último sentido, me refiero al primer contacto. Cuando uno empieza con un programa simple solo se vé la pestaña de código donde trabajar, una barra de herramientas con todo lo necesario para probar los primeros programas, y un solo panel que aparece eventualmente abajo a la hora de la compilación. Digamos que con eso, el alumno ya tiene todo lo que necesita para una clase. No hace falta, por ejemplo, que use los menúes ni busque otros paneles. Con la pestaña de código y la barra de herramientas está hecho. Y la mitad de los elementos de la barra de herramientas son los ya conocidos de cualquier editor. Digamos entonces que bajo esa perspectiva, lo que necesita conocer o explorar de la interfaz para empezar a programar es muy muy poco, casi que nada.

 Así se ve ZinjaI en la primer ejecución... ¿tal vez deba limpiar un poco más la barra de herramientas?

¿Qué pasa con el usuario experto? Bueno, este usuario tiene a su disposición y muy a mano todos los menúes, donde puede explorar practicamente todas las funcionalidades del sistema. Analicemos ahora el criterio de los menúes:
  • Archivo tiene todo lo relacionado a abrir/guardar/crear y además acceso a las preferencias generales (esto es una "costumbre", algunos programas ponen esto en "archivo", otros en "edición", no se si tiene justificación o es por descarte).
  • Edición tiene todo lo necesario para editar y moverse por los fuentes, tanto comandos comunes de cualquier editor de texto, como algunos específicos para código C++.
  • Ver controla todo lo relacionado a la apariencia y composición de la interfaz que uno pueda querer cambiar durante la marcha (otras cosas que no cambian mucho están solo en las preferencias).
  • Ejecución tiene todo lo necesario para compilar y ejecutar el programa.
  • Depuración, como su nombre lo indica, agrupa absolutamente todo lo que tenga que ver con la depuración, mostrando primero lo que más se usa, y al final las cosas raras que la mayoría no va a necesitar.
  • Ayuda tiene lo clásico: ayudas, referencias, actualizaciones, acerca de...
  • Herramientas... para todo lo demás existe herramientas. Este el menú comodín donde van a parar todas las demás cosas, que no siempre tienen relación entre sí. Digamos que este es el menú interesante para el usuario avanzado, donde puede encontrar ayudas para tareas muy particulares o no tan frecuentes. Tareas para nada indispensables en el aula, pero que conviene tener a mano y automatizadas cuando se las necesita en un proyecto. Las pocas cosas que un alumno podría querer usar de este menú, en general pueden accederse de otras formas (como desde los menúes contextuales).
Los menúes "Edición" y "Herramientas" están particularmente sobrecargados.

Algunos días me preocupa seriamente que los menúes estén tan sobrecargados, otros días no. Pensando en un usuario avanzado, no me preocupa mucho que los menúes crezcan. Este usuario aprenderá dónde están las cosas que le interesan, confío en que no le costará trabajo encontrarlas (después de todo no son tantos, y está todo ahí). Y en realidad, con el tiempo pondrá esos comandos en su barra de herramientas, o se acostumbrará a usar los atajos de teclado, y entonces tampoco necesitará del menú. Yo en mi notebook casi no lo toco, uso los atajos y la barra de herramientas para todo. En ese sentido, el menú pasa a ser un primero un muestrario de funcionalidades, y luego solo un plan B para el día a día. Es clave entonces acá, permitir al usuario personalizar las barras de herramientas y/o los atajos de teclado fácilmente una vez que identificó las acciones que le interesan (por eso toooodo en el menú tiene ícono). Creo que eso más o menos se cumple desde hace ya varias versiones.

Queda por mencionar un par de variantes para los usuarios con gustos particulares, y un par de trucos para cuando las cosas no parecen tan a mano:
  • Primero, está el tema pendiente de los paneles acoplables. Si los paneles que van apareciendo distraen u ocupan mucho espacio en una pantalla muy chica (como una netbook o notebook), se puede ir al menú preferencias, activar la opción "Ocultar paneles automáticamente", y reiniciar ZinjaI. En este modo, por cada panel de uso frecuente, hay una pequeña área en uno de los márgenes de la ventana principal con su nombre. Al pasar el mouse sobre el nombre de un panel, éste se despliega, y al quitar el mouse del mismo vuelve a desaparecer. Si se quiere mantener visible un rato, un simple click lo fija. Entonces, todo está muy al alcance, pero sin quitarle espacio al área central del código.
Paneles auto-ocultables. Aparecen solo los nombres en los margenes de la ventana, y 
se despliegan al pasar el cursor del mouse por encima (como el árbol de símbolos en este ejemplo).
  • Luego, para quienes quieren algo todavía más minimalista, está el modo pantalla completa. Se accede a este modo con F11, y desde las preferencias se puede configurar qué debe permanecer visible, y qué no al pasar a este modo. Entonces, se puede, por ejemplo, ocultar todo menos la barra de menúes (comportamiento por defecto), para tener acceso a todo, pero "gastar" el menor espacio posible. O también se puede ocultar todo (hasta los menúes), menos las barras de herramientas, y dejar solo a mano los pocos comandos que utilizamos con frecuencia (y para todo lo demás existen atajos de teclado). Entonces, en este modo nada debería molestarlos, ni barras que no quieran, ni la barra de tarea del sistema, ni las decoraciones y bordes de la ventana, nada. Pueden tener así acceso a un aspecto bien minimalista con una sola tecla, o incluso combinar esto con el item anterior. Más aún, si tienen una pantalla ancha (los más común en estos días), pueden organizar las barras de herramientas verticalmente; y hasta obtener una funcionalidad que lejanamente recuerde a un ribbon leyendo el próximo punto.
Configuración por defecto para pantalla completa: solo se mantiene la barra de menúes

Configuración alternativa para pantalla completa: solo se mantienen las barras de herramientas,
colocadas en este ejemplo en el margen izquierdo y con íconos más grandes.

  • Finalmente, los menúes contextuales. En las últimas versiones (más o menos desde que agregué lo de los atajos de teclado), empecé a mejorar y poblar más los menúes contextuales. Entonces, muchas acciones están ahora disponibles de esta forma, y ya no hay que ir a buscarlas en los sobrepoblados menúes de la ventana principal. Algunos menúes contextuales que habría que mirar son: el de la pestaña (click derecho en la solapa de la pestaña, donde ven el nombre del archivo), los del código (click derecho en algún identificador o alguna selección, y click derecho en el margen, donde aparecen los puntos de interrupción y números de línea), y el de la barra de herramientas (click derecho en alguna herramienta). Notar que estos menúes son contextuales, entonces, qué veamos en ellos depende del contexto en el que hacemos click. Por ejemplo, en el código no es lo mismo hacer click derecho cuando hay selección o cuando no, o hacer click derecho sobre un identificador, o sobre una constante. El ejemplo más claro y tal vez menos conocido es el de la barra de herramientas. Al hacer click derecho sobre una herramienta, el menú contextual muestra otros comandos relacionados al que se le hizo click. Por ejemplo, si tienen el botón para lanzar el análisis estático de CppCheck, con click derecho acceden rápidamente a su configuración, o a ver resultados anteriores sin relanzarlo. Y un caso particular y muy útil es el de el botón de opciones de compilación y ejecución que, cuando hay un proyecto, permite cambiar el perfil activo sin acceder al cuadro de diálogo.
Menú contextual para un comando de la herramienta CppCheck: ofrece ítems para lanzar
el análisis, configurarlo, mostrar resultados previos, y abrir la página de ayuda.

Menú contextual para el botón de opciones de compilación y ejecución: permite cambiar el perfil actual. 

Menú contextual para una pestaña de código.

Menú contextual para el margen del código, ofrece operaciones por líneas.


Menú contextual para un identificador en el código: además de las operaciones de 
edición básicas, ofrece atajos algunas ayudas y herramientas específicas.

Espero que con esto se hayan dado una idea de cuáles son los lineamientos básicos detrás de la organización de los elementos en la interfaz de ZinjaI. No es para dar una clase de diseño de interfaz (de hecho hay muchos errores, y cosas que habría que pensar mejor), sino para entender cómo viene la mano y que eso los ayude a encontrar lo que buscan más fácilmente. Y de paso, les conté sobre algunas opciones que no todos conocen y que les pueden llegar a gustar. Si quieren participar, cuenten en los comentarios qué configuración de la interfaz cambiarían y por qué, o qué valor por defecto en las preferencias les parece que no es el adecuado.

1 comentario:

  1. pienso que las barra de cintas es un manera de operar muy rápidamente una app, acabo de encontrar una app que usa una muy simple barra de cintas

    por favor darle un vistazo a

    http://www.nch.com.au/wavepad/es/screenshots.html

    WavePad, el software de editar mp3 ,música y otros sonidos incluye una grabadora que admite el recorte automático y la grabación activada por voz. Las herramientas incluyen análisis espectral (FFT), generación de tono y síntesis del habla (conversión texto a voz). Una interfaz GUI tan fácil de utilizar que lo tendrá editando en minutos. El reproductor incluye un control de arrastre/señal para una edición precisa.

    ResponderEliminar