No había tenido tiempo de escribir al respecto, esperaba que alguien más tocara el tema antes, pero me sorprende que nadie haya hablado de esto.

Pues bien, hace unos días (el 9 de diciembre) escuché que un operador de la bolsa de Tokio accidentalmente realizó una transacción que bien podría ser el error más caro de esta naturaleza. El empleado activó una orden de venta de 610.000 acciones de J-Com por ¥1 (yen) cada una, en lugar de poner a la venta 1 acción por ¥610.000.

Aparentemente el sistema habría advertido al usuario que la orden era poco usual, pero élignoró el mensaje. El error fue notado posteriormente por una llamada telefónica para confirmar la veracidad de la orden, pero el empleado no pudo inactivar la orden de venta.

El error generó un caos financiero que causó pérdidas inconcebibles a la compañía que administraba las acciones y al mercado en general.

Probablemente en este punto ya tendrán muy claro que tras el error hay una serie de problemas de diseño que permitieron que eso ocurriera:

• Un corredor de bolsa es un usuario muy particular: permanentemente estresado y operando contra el tiempo, por lo que el manejo de situaciones como las confirmaciones de acciones y los mensajes debe ser cuidadosamente considerado;
• El sistema permitió que el corredor ejecutara una acción poco frecuente, sin reforzar de modo apropiado la importancia de ésta, esto es una falla del manejo de la confirmación de las tareas y de la comunicación con el usuario, que permite elacostumbramiento ante los mensajes de alerta, probablemente por el uso de un formato estándar de respuesta: seguramente el usuario hizo clic en OK o Aceptar sin leer el mensaje;
• El sistema no permitió la anulación de la orden de venta, desconozco los detalles del flujo de venta de acciones, pero esto es algo que podría preverse;

Por la importancia de un sistema que maneja las acciones y la economía de todo un país, es vital que todos estos detalles se tomen en cuenta, si no las consecuencias pueden ser muy graves. En el caso que les comento, el error principal es del sistema, antes que del usuario: el sistema permitió y facilitó que el error ocurriera.

Este es un caso extremo, en el que las consecuencias de un error son muy caras. Normalmente la situación no es tan dramática, pero nos permite reflexionar sobre la relevancia de un diseño que considere a los usuarios, sus características y necesidades.

Más información sobre el incidente:

• Resultados en Google News
• The unthinkable at the TSE
• Stock Fiasco Damages Exchange’s Reputation
• J-Com’s Tokyo Debut Marred by $2.8 Bln Trading Error
• Too fat, too fast. The £1.6bn finger
• Typing Error Triggers Loss of 240 Billion Won

Desde hace un tiempo vengo observando un problema común que sorprendentemente parece no haber llamado mucho la atención. Me refiero al manejo de claves en los formularios, tanto en sistemas de autenticación y acceso, como en registro de usuarios nuevos.

Como medida de seguridad razonable HTML define un tipo de input, o campo de ingreso de texto especial, definido por el atributo type como password. La propia definición indica que a diferencia del input de texto y los de tipo password es que estps últimos deben enmascarar su contenido mediante caracteres como asteriscos:

Like “text”, but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks).

Si bien esto es razonable y provee una aparente seguridad (sólo aparente, porque el texto de la clave es siempre accesible), es común que los usuarios se equivoquen al ingresar una clave y que la única manera para corregirla sea borrar todo y escrirla nuevamente. El problema es más severo en situaciones como el registro de un nuevo usuario, en que es común solicitar la creación de una clave y el uso de un segundo campo para confirmar la clave original. En estos casos, ante cualquier duda, el usuario debería borrar ambos campos, el de clave y el de confirmación, y escribirlo todo nuevamente.

Pero también es común que ocurra otra situación, que personalmente he hecho y que además he observado en otros repetidas veces: cuando se solicita la confirmación de una clave, el usuario copia la clave escrita originalmente y la pega en el nuevo campo. Si la clave estaba mal escrita, terminará sin poder acceder al sistema porque la clave registrada no era la que pensó que había escrito. Este es un problema severo.

Soluciones

La lógica de ocultar la clave tiene sentido cuando el usuario no está solo, pero si se encuentra en una situación de confianza es perfectamente razonable que pueda ver el texto que está ingresando como clave. Para esto se podría implementar un mecanismo que permita alternar entre un campo de clave convencional, presentado por defecto, y otro que revela el contenido de la clave, para confirmar que se ha escrito correctamente.

El modelo base es simple:

1. Al presentar el formulario, por defecto se muestra un campo de clave estándar, con el contenido enmascarado, acompañado de un botón etiquetado mostrar o algo similar.
2. El usuario puede revelar el contenido del campo presionando el botón mostrar.
3. El campo muestra el contenido de la clave en texto legible y cambia la etiqueta del botón a ocultar.

En términos de interacción todo va bien hasta acá, pero dependiendo de la técnica utilizada para cambiar las características del campo de clave, tendríamos que realizar un paso extra antes de enviarlo al servidor para procesarlo: si se utilizó JavaScript para alternar entre dosinputs, uno tipo password y otro tipo text, es necesario sincronizar el contenido de ambos antes de ejecutar el submit, e incluso, entre cada cambio de estado entre los dos campos porque el usuario pudo haber editado el texto. Por lo tanto, el flujo completo debería quedar del siguiente modo.

1. Al presentar el formulario, por defecto se muestra un campo de clave estándar, con el contenido enmascarado, acompañado de un botón etiquetado mostrar o algo similar.
2. El usuario puede alternar el estado del campo entre enmascarado o descubierto
   1. El usuario hace visible el texto (desenmascara)
   2. Edita el contenido de la clave
   3. Se sincroniza el texto de los dos campos, el enmascarado y el descubierto
   4. Se repite el proceso tantas veces el usuario cambie de estado
3. Usuario presiona el botón submit.
4. Nos aseguramos de sincronizar el contenido de los campos.
5. Se ejecuta el envío de los datos al servidor.

La verdad es que estoy considerando la implementación más compleja que implica usar dos campos y alternarlos mediante JavaScript, pero teóricamente debería ser posible alternar los estados simplemente cambiando el atributo type del elemento, con lo que se conservaría el valor y el ID del input, sin que sea necesario realizar ninguna sincronización. No lo he problado, pero lo haré pronto.

Por ahora, pueden probar el ejemplo que creé para esto. La implementación es sencilla y estándar y requiere de JavaScript y CSS. El ejemplo no separa el comportamiento del HTML, eso es el siguiente paso y lo haré en cuanto tenga un tiempo.

Si hay interés, puedo explicar en detalle la implementación del script del ejemplo. Espero sus comentarios.