El botón mágico es un anti-patrón común en las interfaces gráficas de usuario . [1] [2]
En esencia, el anti-patrón consiste en un sistema dividido en dos partes: interfaz de usuario y lógica empresarial , que se acoplan a través de un solo punto, haciendo clic en el "botón mágico" o enviando un formulario de datos. Como es una interfaz de un solo punto, esta interfaz se vuelve demasiado complicada de implementar. El acoplamiento temporal de estas unidades es un problema importante: cada interacción en la interfaz de usuario debe ocurrir antes de presionar el botón, la lógica de negocios solo se puede aplicar después de presionar el botón. Cohesión de cada unidad también tiende a ser deficiente: las características se agrupan, lo justifiquen o no, simplemente porque no hay otro lugar estructurado en el que colocarlas.
Inconvenientes
Para los usuarios
Para un usuario, un sistema de pulsadores mágicos parece torpe y frustrante de usar. La lógica empresarial no está disponible antes de presionar el botón, por lo que la interfaz de usuario aparece como un sencillo ejercicio de llenado de formularios. No hay oportunidad de recibir ayuda para completar los campos ni de ofrecer listas desplegables de valores aceptables. En particular, es imposible proporcionar ayuda con campos posteriores, basándose en entradas ya colocadas en campos anteriores. Por ejemplo, una opción de una lista muy grande de códigos de reclamación de seguros puede filtrarse a una lista mucho más pequeña, si el usuario ya ha seleccionado el seguro de hogar / automóvil / mascota, o si ya ha ingresado su propia identificación y el sistema puede determinar el conjunto de riesgos para los que están realmente cubiertos, omitiendo las pólizas oscuras que ahora se sabe que son irrelevantes para esta transacción.
Uno de los aspectos más desagradables de un botón mágico es su tendencia a que la interacción del usuario continúe ingresando un gran volumen de datos y luego rechazándolo por alguna razón inesperada. Este es un diseño particularmente pobre cuando se combina con los infames mensajes "Rehacer desde cero" de los sistemas más antiguos. Incluso cuando se devuelve un formulario con los datos ingresados preservados y el campo del problema resaltado, todavía es desagradable para los usuarios tener que regresar a un campo que pensaban que habían completado unos minutos antes.
Estas características, y la falta de un botón mágico, son particularmente importantes para los usuarios ingenuos que probablemente cometan errores, menos para los expertos o los propios programadores del sistema. La web ha destacado este tipo de fallas en la interfaz y la necesidad de admitir más usuarios públicos, en lugar de un grupo de usuarios más tradicional de trabajadores de oficina basados en roles, que realizan las mismas tareas en el mismo sistema, una y otra vez. A pesar de que un desarrollador que conoce el sistema íntimamente y puede ingresar datos perfectamente la primera vez puede usarlo de manera eficiente, esto no indica que dicho sistema sea adecuado para que lo usen sus usuarios reales.
Para la implementación
El botón mágico a menudo surge a través de una mala gestión del proceso de diseño en las primeras etapas, junto con una falta de importancia en la experiencia del usuario, en relación con la finalización del proyecto. A simple vista, la simplicidad del botón mágico es atractiva ya que tiene pocos módulos de interfaz de usuario y sus interacciones también parecen simples. Esta vista oculta la complejidad dentro de cada módulo y también devalúa la calidad de la interfaz en relación con el costo.
Alternativas
En un sistema moderno (es decir, uno en el que el procesamiento es barato y los estándares de interfaz de la competencia son altos), los usuarios simplemente no deben ingresar datos durante largos períodos sin alguna interacción automática para guiar, validar o adaptar el sistema de acuerdo con el desarrollo. estado de los datos que han ingresado hasta ahora. Dejarlos solos para que "sigan adelante", y luego validar todo al final, significa que las correcciones necesarias se detectarán cada vez más desde el momento en que se ingresaron los datos. Como principio a priori , las correcciones necesarias deben resaltarse tan pronto como se acerquen al momento en que se ingresan o podrían identificarse por primera vez.
En una interfaz impulsada por eventos, la mayoría de los eventos desencadenados por la "finalización" de un campo presentarán una oportunidad para validar ese campo o para guiar las opciones para ingresar el siguiente. Incluso pueden controlar a qué campo se lleva al usuario a continuación: las subsecciones de un formulario a menudo se vuelven relevantes o irrelevantes por los valores ingresados al principio, y los usuarios no deberían tener que omitirlos manualmente, si se puede hacer por ellos.
En este escenario, el programador dibuja primero la interfaz de usuario y luego escribe la lógica empresarial en los métodos creados automáticamente .
Ejemplo
El siguiente es un ejemplo típico de un botón mágico en Borland Delphi :
procedimiento TForm1 . Button1Click ( Remitente : TObject ) ; var reg : TRegistry ; begin reg : = TRegistry . Crear ; prueba reg . RootKey : = HKey_Current_User ; si reg . OpenKey ( '\ Software \ MyCompany' , verdadero ) luego comience reg . WriteString ( 'Nombre de archivo' , Editar1 . Texto ) ; terminar ; finalmente reg . Libre ; terminar ; terminar ;
Una mejor manera de hacer esto es refactorizar la lógica de negocios (en este ejemplo almacenando el nombre del archivo en el registro) en una clase separada.
escriba TPreferences = class private FFilename : String ; procedimiento SetFilename ( valor constante : String ) ; propiedad pública Nombre de archivo : String read FFilename write SetFilename ; procedimiento de carga ; procedimiento Guardar ; terminar ;
y llame a esta clase método Save desde el controlador Click:
procedimiento TForm1 . Button1Click ( Remitente : TObject ) ; comenzar Preferencias . Guardar ; terminar ;procedimiento TForm1 . Edit1Change ( remitente : TObject ) ; comenzar Preferencias . Nombre de archivo : = Editar1 . Texto ; terminar ;
Referencias
- ^ "AntiPattern (por Indranil Nandy, IIT Kharagpur)" .
- ^ Anders Toxboe (5 de febrero de 2009). "Anti-Patrones de Interfaz de Usuario" . Patrones de interfaz de usuario.