Muhit: ¿Cómo funciona una decisión de diseño en pantalla?

Conservar un filtro, explicar una operación fallida y permitir que alguien vuelva al trabajo que empezó. El enfoque de diseño de Muhit se hace más claro cuando estas pequeñas decisiones se concretan en la práctica.

En el primer artículo abordé Muhit como un lenguaje compartido de comportamiento. La coherencia de una interfaz dependía tanto de cómo continúa el trabajo de una persona entre pantallas como de sus colores y tipografías.

Para ver cómo se concreta esta idea, podemos seguir una secuencia pequeña: encontrar un registro, abrirlo, escribir una nota y volver a la lista.

Uno de los ejemplos actuales de desarrollo de Muhit se organiza alrededor de esta secuencia. Contiene unos pocos registros, como un marco de investigación, recursos compartidos y notas de decisiones. La persona filtra la lista mediante una búsqueda, abre un registro y escribe una nota. Al volver a la lista y abrir de nuevo ese registro, se conservan tanto la condición de búsqueda como la nota.

Parece una interacción corriente. Pero hacerla posible exige decidir qué recuerda la interfaz, cuándo lo olvida y qué le comunica a quien la utiliza.

Decisiones alrededor de un registro

En el ejemplo, el borrador de cada registro se conserva bajo su propio identificador. Así, una nota escrita para un registro no aparece en el campo de otro. Volver a la lista no borra el borrador y el buscador mantiene la condición que dejó la persona.

Esto evita tener que reconstruir el trabajo al regresar a la pantalla. No hace falta repetir la búsqueda, encontrar otra vez el registro correcto ni intentar recordar la frase recién escrita.

El tiempo de conservación también forma parte del diseño. Los borradores del ejemplo permanecen únicamente en la memoria de la página abierta. Se pierden al recargar la página o cerrar la pestaña. Ese límite se indica expresamente junto al área de edición.

El principio de preservar el esfuerzo se convierte así en una pregunta concreta: ¿Qué información conservamos, dentro de qué ámbito y durante cuánto tiempo?

Otra decisión aparece en el cambio de foco entre vistas. Al abrir un registro, el foco del teclado pasa al encabezado del detalle. Al volver a la lista, regresa al botón de ese registro.

La transición visual tiene así una correspondencia para quien usa el teclado. Queda claro dónde empieza la nueva vista y en qué punto se encuentra al regresar.

Una búsqueda sin coincidencias también tiene un estado propio. Se informa de que no hay registros que coincidan y se ofrece borrar la búsqueda. No se presenta como un fallo de carga. El paso siguiente es distinto: para cambiar los resultados hay que modificar la consulta; ante una petición fallida, puede tener sentido reintentar.

El error y la cancelación dentro del recorrido

El mismo ejemplo incluye una opción para provocar deliberadamente un fallo en la operación. El objetivo es estudiar la recuperación además del recorrido que funciona sin problemas.

Cuando la persona escribe una nota e inicia la operación, la interfaz pasa a un estado de espera. Se impide el envío duplicado, la nota no puede modificarse mientras la operación está pendiente y aparece un control para cancelarla.

Si la operación de ejemplo falla, la nota permanece. El mensaje explica qué ha ocurrido y cómo volver a intentarlo. La etiqueta del botón también se adapta al nuevo estado.

El error no obliga, por tanto, a repetir todo el recorrido desde el principio. Alrededor de la operación fallida queda un espacio desde el que continuar.

La cancelación recibe la misma atención. Si la persona cambia de idea durante la espera, la operación de ejemplo se detiene; el borrador se conserva y se informa de que no hubo confirmación. Un resultado tardío de la operación anterior no puede convertir después la pantalla en un estado de éxito.

Esta distinción exige más cuidado en una aplicación conectada a un servidor real. Cancelar una petición en el cliente no demuestra por sí solo que se haya deshecho una operación ya iniciada en el servidor. La aplicación debe evaluar por separado el resultado real.

Ese límite también se ve en las integraciones de referencia de Muhit para React y Vue. Al reconstruir el formulario se genera una señal de cancelación para la operación pendiente. La aplicación debe transmitirla a la petición de red y evitar actualizar su propio estado con una respuesta cancelada.

Aquí se encuentran las responsabilidades de la biblioteca y de la aplicación. El componente gestiona el ciclo de vida de la interacción; la aplicación sabe si el registro se ha guardado realmente.

Por eso el botón del pequeño ejemplo funcional se llama «Confirmar localmente». El éxito expresa una confirmación únicamente en la memoria de esa pestaña. No da a entender que se haya guardado nada en un servidor o almacenamiento persistente.

El alcance de la respuesta debe coincidir con el alcance de la operación que realmente se ha realizado.

Llevar el mismo enfoque a otras pantallas

Implementar de nuevo estas decisiones en cada proyecto se vuelve difícil con el tiempo. Los componentes pueden necesitar reconstruirse, especialmente al cambiar el idioma, el tema o la vista.

En las referencias de React y Vue de Muhit, antes de reconstruir una tabla se captura una instantánea de la vista actual. En los recorridos compatibles, los filtros, la selección y la disposición de las columnas pasan al nuevo componente. Si la aplicación proporciona expresamente un valor nuevo, ese valor tiene prioridad.

Este detalle aclara quién es responsable del estado. La información que la aplicación deba controlar continuamente tiene que reflejarse en su propio estado a través de los eventos de cambio correspondientes. Debe saberse dónde se gestiona el comportamiento que se espera conservar tras cada redibujado.

La misma distinción se aplica al adaptador de interfaces JSON de Muhit. Una actualización no válida conserva la vista actual; una actualización correcta la reconstruye. Por esta vía no se transfieren automáticamente los filtros y la selección de la tabla anterior. Si la interacción necesita mayor continuidad, la aplicación debe establecerla mediante la API del componente correspondiente.

Las decisiones sobre temas también siguen funciones definidas. El fondo de una superficie, el texto legible, el énfasis de una acción y el foco del teclado tienen variables separadas. Por ejemplo, --mh-surface se usa junto con --mh-text, mientras que el texto de un botón destacado usa --mh-on-accent.

Esta estructura facilita seguir el significado del componente al cambiar la paleta. Aun así, hay que examinar la pantalla real: ¿se entiende qué elemento está seleccionado? ¿Se ve el foco? ¿Siguen siendo cómodos los controles en una disposición más densa?

Por eso, al incorporar Muhit a un proyecto, me parece útil empezar por una tarea pequeña que pueda seguirse de principio a fin, antes que por la pantalla más vistosa. Encontrar y editar un registro puede ser suficiente.

Después hay que recorrer la misma tarea en distintas condiciones: cuando no hay coincidencias, cuando falla la operación, cuando la persona cambia de idea, al cambiar de idioma y al usar el teclado.

Estos ejemplos muestran comportamientos funcionales. La aceptación en dispositivos reales y la evaluación manual con lectores de pantalla siguen entre las comprobaciones pendientes.

Así toma forma lo que busco en la aplicación de Muhit: una decisión de diseño se hace visible cuando alguien puede continuar el trabajo que empezó. Cuando su nota sigue en su sitio, el error se entiende y la confirmación en pantalla cuenta lo que realmente ocurrió.

---

Este artículo se basa en los principios de diseño, el flujo funcional de registros y los contratos de integración del código local de desarrollo 0.16.0 de Muhit. Los ejemplos no afirman un uso en producción ni una aceptación manual de accesibilidad completada.

Recursos: Código fuente de Muhit · Contrato de interfaces JSON

Artículo anterior: Muhit: ¿Qué hace coherente una interfaz?

Conceptos del Atlas: Diseño · Software · Contexto · Sistemas