Pattern against user

Mucha gente no está consciente del daño que hacen, a sí mismos y a los demás.

Una aplicación web puede actualizarse cargando los datos via Excel. El usuario descarga un Excel con los espacios en blanco, los llena y lo carga de nuevo al sistema. Problema: El programa no está aceptando un archivo específico. ¿Cómo lo podemos arreglar?

En manos inexpertas Excel es tan peligroso para los datos como Word lo es para los formatos.

No me malinterpreten: Word es superior. Decidí calar desde dónde empieza la superioridad de Word descargando la versión 5.5 para DOS y encontré con gusto que desde ahí puedes aplicar el equivalente tecnológico a las CSS. Desde 1991. Y quizás desde 1981, pero no tengo pruebas de ello.

El problema es que ningún usuario se molesta en aprender estilos. Es como echar los jitomates a la licuadora y luego picotearlos con el cuchillo cebollero en lugar de encender el aparato. He visto gente que terminaba sus párrafos al llegar al final de la página, como si fuera una máquina de escribir. Y bueno, eso fue mi tía, que nunca había visto una computadora, pero ténganla presente.

Y con Excel la cosa no es muy distinta. Cada celda puede (y debería) tener un tipo de datos bien definido, haciendo así buena distinción entre valores numéricos, porcentuales, fechas, textos y demás; pero siempre confiamos en el formato General. Generalmente hace un buen trabajo, huh.

Los problemas comienzan cuando te das cuenta que Excel está podrido por dentro. No me considero un veterano (a pesar de 17 años programando) pero sé que si quiero calcular el seno de un ángulo puedo recurrir a la función sin. Y es razonable en cualquier contexto excepto en Excel, donde tengo que usar la función seno. ¿Y para sumar rangos? No sum, suma. Hay funciones razonables, como curtosis, pero en general esto significa que no puedes copiar de la 'net un ejemplo y pegarlo en tu hoja de cálculo.

Pero definitivamente no es lo más grave: en España (y otros países) el símbolo separador de decimales es la coma (,). Casualmente también es por defecto el separador de argumentos en las definiciones. Así que si vives en una región de coma decimal ahora tendrás que separar todo con punto y coma (;).

No parece gran cosa, pero consideren estos dos ejemplos:

En mis tiempos como soporte técnico de Prodigy había un cierto comando que había que teclear escribiendo el símbolo de punto y coma. Esto era muy difícil de explicar por teléfono pues mucha gente no sabe de la existencia del punto y coma, y escribían un punto y una coma (.,). No estamos hablando de analfabetas, sino de gente que es capaz de prender la computadora y tratar de picarle los botones, con iniciativa suficiente como para llamar por teléfono y seguir instrucciones simples… Aunque debo admitir que el IQ del usuario cae unos 40 puntos cuando está siguiendo instrucciones, al grado que gente que hablaba buen inglés y era razonable leía la palabra gateway y en lugar de pronunciarla géitwey decía gátogüey.

Hay gente lista. Hay gente carismática. Hay gente lista y carismática. Y desafortunadamente también hay gente que no es ni lista ni carismática. Así había un líder de proyecto que se ganó el desprecio de sus colaboradores. Un día nos llama:

Miren, les voy a enseñar un truco en el Excel. Si quieren que no salgan las rayitas de las celdas lo que tienen que hacer es seleccionar todo (va a la celda A1, oprime shift y recorre el cursor hasta la derecha y luego hasta abajo, hasta llegar a la IV65536), y entonces le dan clic aquí (en Relleno de celda) y eligen color blanco. ¡Ahí está!

Si consideramos que el mismo tipo usaba MS Paint como procesador de textos (en lugar de, digamos, Word), entonces suena a que era un simple usuario inexperto y no iniciado en las artes. Una persona capaz de encontrar la solución a sus problemas dentro del caos aparente del desconocido universo de la ofimática.

El problema es que no era el Juan Perro que llama a Prodigy para activar la computadora de sus hijos, no. Era un profesional con título universitario en algún campo relacionado con la informática y ganando un salario que muchos ya quisiéramos.

Si los usuarios que supuestamente tienen preparación son capaces de estas aberraciones, ¿de qué serán capaces los que no tienen capacitación alguna?

¿Qué hacemos con el archivo que el sistema no acepta? La solución es sencilla: hay que ir con el usuario a ver cómo lo hizo. Lo más probable es que le hizo algo al que no sirve (y no sabe qué le hizo (y si lo sabe no lo admitirá)), y cuando lo estemos observando hará las cosas tal y como se las enseñaron. Y desde luego que entonces el programa funcionará.

Esa es, por cierto, la única explicación científica que puedo ofrecer de por qué las cosas funcionan bien cuando tienes que mostrarle el error al técnico. Este fenómeno es un ejemplo más de lo que en algunos campos se conoce como Ley de Murphy.

¿Y qué podemos hacer nosotros como desarrolladores?

Limita las posibilidades del usuario: No tiene caso permitirle que pueda especificar 17 formatos diferentes de fecha si tú sólo puedes procesar uno. Lo único que causa es confusión y frustración cuando algo que aparentemente debería funcionar no lo hace. En el caso del Excel, si ya estás generando un Excel, incluyele fórmulas que validen los datos mientras el usuario los llena.

Evita los formatos complejos: No pidas archivos en Word o Excel si un archivo .txt o un .csv serían suficientes. Esto es en beneficio tanto del usuario como del desarrollador: las automatizaciones de Office desde ASP están oficialmente no-soportadas (es decir, Microsoft explícitamente ha dicho que no lo hagas).

Emite mensajes de error significativos: Puede ser que el usuario no los entienda, pero la gente de soporte y los programadores sí. Algunos usuarios sí leen y entienden los mensajes, y corrigen sus propios errores — aunque dicha variedad está en peligro de extinción. Pero los programadores del futuro usarán ese mensaje para buscar en tu código fuente, asegúrate de que no se repitan para facilitarles el trabajo y limpiar tu karma.

Haz interfaces sencillas: El problema se origina porque la interfaz original está basada en una versión obsoleta del FlexGrid, programada de una forma tan pobre que se tarda muchísimo en cargar y procesar. Si hubieran hecho un trabajo más enfocado entonces no habría necesidad de cargar los datos via Excel en primer lugar.

El mundo no es óptimo. Si puedes cambiar una parte, por pequeña que sea, asegúrate de hacer un buen trabajo.