Las GUI también pueden ser 100% controladas por teclado

La accesibilidad del teclado es una de esas cosas que tienden a barrerse bajo la alfombra u olvidarse por completo junto con la accesibilidad en general. Lo curioso es que la primera suele derivarse de la segunda.

Parte de la culpa recae sobre los hombros de los frameworks de UI populares (o en el caso de quienes optan por no usarlos, los desarrolladores que tomaron esa decisión). Los frameworks más antiguos tienden a hacer esto bastante fácil; por ejemplo, en Cocoa/AppKit (el framework de UI nativo de Mac), uno puede conectar fácilmente toda su UI para una navegación adecuada por teclado de manera completamente visual (principalmente consiste en conectar el outlet nextKeyView entre controles para producir una cadena lógica para enfocar con tabulador). Definir atajos de teclado también es simple; agrega un elemento de menú para un comando y establece su atajo correspondiente (lo que a su vez permite al usuario reasignar el atajo en Configuración del Sistema a voluntad).

Ese tipo de diseño ha caído en desgracia con los frameworks más nuevos, desafortunadamente. El nuevo estilo preferido parece ser un wireframe donde el desarrollador elige qué partes se rellenan, y a menudo solo lo más esencial se incluye.

La experiencia del usuario avanzado no es lo mismo que la experiencia del usuario en general. Si quieres argumentar que todas las herramientas de desarrollo deberían estar impulsadas por teclado, adelante, allá tú. Pero la mayoría de la gente no está dispuesta a lidiar con la curva de aprendizaje de las GUI impulsadas por teclado, y eso está bien. No deberíamos forzarlo.

La insistencia de HN en actuar como si todos los usuarios fueran perfeccionistas de la eficiencia tipo Arch Linux es dolorosamente cursi.

(Esto suena más duro de lo que pretendía. Lo siento. Amo a la gente de Arch Linux. Solo creo que no es menos noble servir al usuario promedio que crear la herramienta perfecta para usuarios avanzados).

¿Qué significa realmente que una GUI esté impulsada por teclado?

La forma obvia es que cada acción simplemente tenga asignado un atajo.

Mi contraargumento sería que eso no es realmente impulsado por teclado, sino meramente compatible con teclado. Está el problema de la descubribilidad. La mejor práctica actual parece ser mostrar los atajos de los botones en tooltips, elementos de menú, o al presionar otro atajo.

Yo diría que los botones son un desajuste fundamental con los teclados. Una UI impulsada por teclado no debería tener botones.

El problema es que las UIs genuinamente impulsadas por teclado como CLI o TUI sufren de una terrible descubribilidad, que es la razón por la que la UI con ratón existe en primer lugar. Entonces, ¿podemos tener una UI impulsada por teclado que sea tan intuitiva como hacer clic con el ratón?

La última vez que construí una aplicación CRUD (hace unos 24 años) me propuse hacer esto. Recuerdo ver al personal de nóminas volar a través de sus aplicaciones de terminal VAX VMS con tal velocidad y destreza que haría sonrojar a cualquier administrador de Unix versado en el arte de la línea de comandos, y me hizo pensar: "Oh, sí, todas estas GUI de apuntar y hacer clic de los 90 lo entendieron mal. Si se requiere que las personas usen intensivamente un sistema en el trabajo, preferirían una curva de aprendizaje seguida de velocidad, comodidad y destreza sobre una curva de aprendizaje más fácil que intercambie destreza por descubribilidad".

Era un framework de aplicaciones web, pero... todas las pantallas de navegación/listado incluían IDs de fila y un cuadro de texto enfocado, de modo que escribir el ID de fila y presionar Enter seleccionara. Todos los botones de acción tenían un subrayado para indicar qué atajo de teclado Ctrl+Shift los activaba. Todas las pantallas de edición enfocaban por defecto el primer cuadro de texto editable y en ningún momento el ratón era realmente necesario. Finalmente, los tiempos de carga se optimizaron para apuntar a 75 ms.

Divertidamente, la retroalimentación de los usuarios fue: "El control por teclado es bastante bueno, pero ¿puedes hacerlo más rápido?".

Lo que pensé que era un extra resultó ser crítico para que los usuarios no fueran miserables.

Estoy de acuerdo, pero creo que ser usable con el teclado no es suficiente, porque los atajos a menudo son difíciles de descubrir y recordar. Creo que lo ideal es, como en las buenas TUIs, que las GUI muestren pistas obvias en pantalla sobre cómo navegar con el teclado.

Sería realmente genial tener algunos frameworks de GUI para las plataformas comunes (¡incluida la web!) diseñados para hacer esto y tener algunas opiniones sobre atajos comunes para acciones comunes para poder estandarizar algo.

El autor hace un excelente punto. Hay demasiadas Interfaces de Usuario de Terminal (TUIs) pobres creadas solo por tener una TUI. A menudo no están bien construidas o carecen de suficiente pensamiento para ser efectivas/productivas.

Pero la tendencia más amplia en las aplicaciones GUI ha sido apuntar a la cuota de mercado, no ofrecer productividad para los usuarios de teclado. En los años 80 y 90, Photoshop, Illustrator, etc. se convirtieron en los gigantes que son hoy porque se centraron en permitir que los profesionales fueran extremadamente eficientes usando su variedad de poderosos atajos de teclado. En 2026, cuando las empresas de software están muriendo de KPItis calificando su gestión de producto por crear modelos de suscripción convincentes para enganchar clientes, la atención a ofrecer realmente productividad para los usuarios de teclado a menudo es una ocurrencia tardía. Las aplicaciones móviles no tienen atajos de teclado y las aplicaciones de escritorio parecen tratarse cada vez más como el "caso extremo" estrecho con solo unos pocos cientos de millones de usuarios objetivo frente a los miles de millones disponibles en dispositivos móviles. Es una oportunidad para aquellos que se toman en serio ofrecer valor aprovechando el poder de los atajos de teclado para hacer que sus GUIs sean altamente productivas y completamente utilizables desde el teclado. Con todos sus defectos, Microsoft lo hizo bien con VSCode.

> De hecho, muchas guías de aplicaciones de frameworks de GUI alientan explícitamente a los desarrolladores de aplicaciones GUI

En lugar de eso, deberían estar diseñados de manera que permitan a los usuarios evitar a esos desarrolladores de una manera (al menos) consistente con el framework, ya que nunca habrá un momento en que colectivamente se vuelvan "sabios del teclado".

Recientemente tuve una revelación cuando hice una aplicación extendida de controlador MIDI qwerty que muestra permanentemente los estados y funciones de todas las teclas, incluso cuando se mantienen presionados los modificadores.

Se me ocurrió que esta es una manera maravillosa de diseñar software: inmediatamente conoces los atajos de teclado porque ya los estás viendo. Estoy trabajando en tomar lo que he construido para el controlador de teclado MIDI qwerty (que está construido sobre hammerspoon) y convertirlo en una interfaz genérica para cualquier tipo de aplicación.

Si el objetivo final es navegar y controlar la aplicación mediante atajos de teclado, ¿por qué no incorporar eso en el diseño de la propia GUI?

Mi proyecto si tienes curiosidad: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

No podría estar más de acuerdo, pero creo que es principalmente una cosa de "geeks". Uso i3 en mi Linux personal y aerospace en mi Mac de trabajo; vimium en el navegador, Neru en las otras aplicaciones (hace algo similar a Neru). Recientemente terminé encontrando una manera de crear scripts de usuario para aplicaciones Electron y desde entonces estoy agregando extensiones estilo vimium (por ejemplo, en Teams) dondequiera que voy.

Desearía que esto fuera un valor predeterminado, pero también que hubiera más estándares para navegar por las UIs. Por eso me gustan mucho vimium y otras extensiones similares, ya que siguen la lógica de vi en todos los sitios web, en lugar de tener que aprender la idea de cada uno sobre cómo navegar.