Hispanopedia WikiEl botón mágico es un antipatrón común en las interfaces gráficas de usuario . [ 1 ] [ 2 ]
En esencia, el antipatrón consiste en un sistema dividido en dos partes: interfaz de usuario y lógica de negocio , que se acoplan a través de un único punto: pulsar el botón mágico o enviar un formulario. Al tratarse de una interfaz de un solo punto, su implementación se vuelve excesivamente compleja. El acoplamiento temporal de estas unidades es un problema importante: toda interacción en la interfaz de usuario debe ocurrir antes de pulsar el botón, mientras que la lógica de negocio solo puede aplicarse después de pulsarlo. La cohesión de cada unidad también suele ser deficiente: las funcionalidades se agrupan independientemente de si lo justifican o no, simplemente porque no existe otro lugar estructurado donde ubicarlas.
Desventajas
Para usuarios
Para el usuario, un sistema de botones mágicos resulta torpe y frustrante. La lógica de negocio no está disponible antes de pulsar el botón, por lo que la interfaz de usuario se presenta como un simple formulario. No hay posibilidad de recibir ayuda para rellenar los campos ni de acceder a listas desplegables con valores aceptables. En particular, es imposible ofrecer asistencia para campos posteriores, basándose en la información ya introducida en campos anteriores. Por ejemplo, una selección de una lista muy extensa de códigos de reclamación de seguros podría filtrarse a una lista mucho más reducida si el usuario ya ha seleccionado un seguro de hogar, coche o mascota, o si ya ha introducido su identificación, de modo que el sistema pueda determinar el conjunto de riesgos para los que está realmente cubierto, omitiendo las pólizas desconocidas que ahora se sabe que son irrelevantes para esta transacción.
Uno de los aspectos más frustrantes de un botón mágico es la tendencia a que la interacción del usuario comience con la introducción de una gran cantidad de datos, para luego ser rechazada por algún motivo inesperado. Esto es especialmente problemático cuando se combina con los infames mensajes de "Rehacer desde cero" de los sistemas antiguos. Incluso cuando se devuelve un formulario con los datos introducidos y el campo problemático resaltado, sigue siendo frustrante para los usuarios tener que volver a un campo que creían haber completado minutos antes.
Estas características, y su ausencia de una solución mágica, son particularmente importantes para los usuarios inexpertos, propensos a cometer errores, y menos para los expertos o los propios programadores del sistema. Este tipo de fallo de interfaz ha sido puesto de manifiesto en la web, así como la necesidad de dar soporte a un público más amplio, en lugar de a un grupo de usuarios más tradicional de oficinistas con roles definidos que realizan las mismas tareas en el mismo sistema una y otra vez. Aunque un desarrollador que conoce el sistema a la perfección y puede introducir datos correctamente a la primera sea capaz de usarlo de forma eficiente, esto no indica que dicho sistema sea adecuado para sus usuarios reales.
Para su implementación
El botón mágico suele surgir de una mala gestión del proceso de diseño en las primeras etapas, junto con una escasa importancia que se le da a la experiencia del usuario en comparación con la finalización del proyecto. A primera vista, la simplicidad del botón mágico resulta atractiva, ya que cuenta con pocos módulos de interfaz de usuario y sus interacciones también parecen sencillas. Sin embargo, esta visión oculta la complejidad interna de cada módulo y, además, devalúa la calidad de la interfaz en relación con el coste.
Alternativas
En un sistema moderno (es decir, uno donde el procesamiento es económico y los estándares de interfaz son altos), no se debería dejar a los usuarios ingresando datos durante largos períodos sin alguna interacción automática que los guíe, valide o adapte el sistema según el estado de los datos ingresados hasta el momento. Dejarlos solos para que "simplemente continúen" y luego validar todo al final, implica que las correcciones necesarias se detectarán cada vez más tarde desde el momento en que se ingresaron los datos. Como principio fundamental , las correcciones necesarias deben resaltarse tan pronto como se ingresen o se identifiquen por primera vez.
En una interfaz basada en eventos, la mayoría de los eventos que se activan al completar un campo ofrecen la oportunidad de validar dicho campo o de guiar a los usuarios para que ingresen el siguiente. Incluso pueden controlar a qué campo se dirige el usuario a continuación: las subsecciones de un formulario suelen volverse relevantes o irrelevantes según los valores ingresados al principio, y los usuarios no deberían tener que omitirlas manualmente si se puede hacer automáticamente.
En este escenario, el programador primero diseña la interfaz de usuario y luego escribe la lógica de negocio en los métodos creados automáticamente .
Ejemplo
El siguiente es un ejemplo típico de un botón mágico en Borland Delphi :
procedure TForm1 . Button1Click ( Sender : TObject ) ; var reg : TRegistry ; begin reg := TRegistry . Create ; try reg . RootKey := HKey_Current_User ; if reg . OpenKey ( '\Software\MyCompany' , true ) then begin reg . WriteString ( 'Filename' , Edit1 . Text ) ; end ; finally reg . Free ; end ; end ;Una mejor manera de hacerlo es refactorizar la lógica de negocio (en este ejemplo, almacenar el nombre del archivo en el registro) en una clase separada.
tipo TPreferences = clase privada FFilename : String ; procedimiento SetFilename ( const Value : String ) ; propiedad pública Filename : String leer FFilename escribir SetFilename ; procedimiento Load ; procedimiento Save ; fin ;y llama al método Save de esta clase desde el controlador Click:
procedimiento TForm1 . Button1Click ( Remitente : TObject ) ; inicio Preferencias . Guardar ; fin ;procedimiento TForm1 . Edit1Change ( Remitente : TObject ) ; inicio Preferencias . NombreArchivo := Edit1 . Texto ; fin ;Referencias
- Antipatrones
