16 nov 06 Peticiones extrañas

Cuando trabajas en el desarrollo de software tienes que tener en cuenta una cosa muy importante: el cliente manda. Como en todos los sitios, obviamente. Pero además tienes que tener en cuenta una segunda cosa: no importa lo que hagas, no importa cuánto compliques el código, ya que el cliente hará cualquier cosa absolutamente extraña que hará que el sistema reviente de la manera más absurda. Sin embargo, tampoco debes olvidar una tercera cosa: el cliente no sólo no sabe lo que quiere, sino que, habitualmente, no sabe ni siquiera lo que necesita. Es más, en general no sabe nada de la tecnología con la que está tratando (y la mayoría de las veces, ni falta que le hace, y casi mejor así).

Hace algunos días el cliente del proyecto de desarrollo en el que trabajo nos envió el parte de incidencias encontrado. Este parte, es, simplificando, un listado de errores que el cliente ha advertido durante el uso del software entregado. Dado que la entrega no es definitiva, sino que se va haciendo en pasos sucesivos, se pueden ir corrigiendo poco a poco esos errores.

Precisamente me tocó corregir, entre varios, un error especialmente llamativo: el cliente había observado que en un determinado formulario, marcando un determinado campo de texto no editable, si le daba a la tecla de borrado (la que está encima del Intro, el navegador (es una aplicación mediante servicio web) volvía “atrás”.

Como se puede ver, era un petición sumamente sorprendente. Por atrás, según pude experimentar, quería decir al inicio del historial del navegador. Y entonces apliqué el principio de Sherlock Holmes: precisamente los detalles más enrevesados y grotescos de un problema son los que dan la clave para llegar directamente a su solución.

En efecto: hay que saber que en los navegadores (al menos en los más comunes) el pulsar esta tecla hace que se vaya hacia atrás en el historial. Cuando la página en cuestión tiene un formulario, si fijamos la posición con el ratón en uno de los campos, y es editable, bloquea este comportamiento (la tecla de borrado se comporta como tal, y borra el texto que en dicho campo hubiere). Pero al ser un campo de no edición, no ocurría esto. En suma: el cliente se estaba quejando porque al darle a borrar el navegador hacía lo que tenía que hacer.

Ya nos quedamos con la duda: ¿debíamos escalar el problema a Microsoft o a la Fundación Mozilla? ¿O liar la traca con javascript para capturar el evento “pulsado de la tecla de borrado” en las páginas web con formularios, distinguiendo si se está sobre un campo editable? ¿O explicarle al cliente que ese era un comportamiento normal y que, en ese caso, las quejas debían ir al maestro armero? Huelgo decir que optamos por la tercera.

Una cosa curiosa: efectivamente tanto Firefox como IExplorer se comportaban de la manera descrita, pero Firefox, usando el motor de Internet Explorer (cosa que se puede conseguir con el plug-in IE-Tab -sólo para Windows, obviamente) no lo hacía. De hecho, eso fue lo que más me fascinó de todo este asunto.