La multidisciplinariedad de la informática hace que a los programadores no nos baste con saber crear una aplicación o una web fiable, segura, robusta o eficiente, sino que además muchas veces tenemos que aprender sobre temas tan variados como contabilidad, gestión de inventarios, rutas de visitación médica, incidencias en vías ferroviarias, operatividad en celdas de telefonía móvil, temperatura de prensado del aceite de oliva… En resumen, que toca empaparse del dominio de negocio de nuestro cliente, ya que si no sabemos cómo funciona, difícilmente podremos hacer una aplicación que se ciña a sus necesidades reales.
El primer punto problemático en ese sentido, y al que pocas veces se le presta toda la atención que merece, es el proceso de registro de los usuarios en la aplicación. ¿Os imagináis que quisierais vender una casa estupenda, pero el portal fuera horrible o de difícil acceso? Pues eso es lo que hacemos cada vez que no diseñamos correctamente el formulario de registro, lo que suele ocurrir porque lo hacemos de forma mecánica, sin hacernos antes varias preguntas relevantes acerca del mismo.
¿Realmente necesitamos un registro?
La primera pregunta es obligatoria y sin embargo es la que más veces obviamos. ¿De verdad necesita nuestra aplicación un registro? Hay que cambiar el chip, olvidar por un momento que somos desarrolladores y pensar en cómo nos comportamos cuando nosotros somos los usuarios y veremos que en muchas ocasiones una solicitud de registro nada más empezar, sin ni siquiera permitir echar una ojeada, es lo que tira para atrás a gran cantidad de posibles usuarios.
No nos engañemos: no nos gusta registrarnos. Si no, no existirían páginas como BugMeNot, en las que los navegantes están dispuestos a utilizar un usuario creado por vetetúasaberquién con datos falsos y preferencias desconocidas. Pero claro, si quieres leer una respuesta de un supuesto experto en un foro, y para esos 30 segundos que vas a dedicar a leer, requieres invertir otros 5 en pasar todo un proceso de registro, con su confirmación de e-mail incluida, es normal
Y en el caso de las aplicaciones para móviles, el error puede ser todavía más sangrante. Descargar una aplicación gratuita para ver de qué va, y que la única pantalla a la que puedas acceder sea a la de login y registro es una muy mala estrategia por parte del desarrollador, que espantará a sus usuarios antes de que puedan saber si la aplicación les gusta o no.
La pantalla principal de Foursquare en iPhone sólo tiene dos opciones: registrarte o identificarte
Unos que han aprendido muy bien esta lección son las tiendas online: tú vas realizando toda la compra, pudiendo ver todos los artículos y añadirlos a tu carrito o cesta de la compra de forma “anónima”, y sólo en el caso de querer realizar el pago se te solicitan los datos personales. Y de hecho, en algunas de ellas ni siquiera es necesario crear un registro perenne, sino que se puede hacer como visitante ocasional y se considera que tus datos son sólo para facturación y envío de ese único pedido. Y he entrecomillado lo de “anónima” porque a veces sí que se identifica tu IP, o tu navegador, o se te deja una cookie, para que puedas dejar la compra a medio y continuarla sin necesidad del engorro del registro.
¿Necesito el e-mail y otros datos típicos?
Otro fallo común es pedir más información de la cuenta movido por la fuerza de la costumbre. Por una parte, a nuestro cliente le puede el ansia viva y considera que todos los datos son imprescindibles y deben aparecer como obligatorios. De la otra parte, nuestro usuario querría no tener que introducir ningún dato personal, y que bastase con introducir apodo y contraseña. Y en medio de esa contienda estamos nosotros, obligados a encontrar una solución intermedia que sea útil, razonable y legal.
De entre los datos que están en casi todos los formularios de registro y que quizá no necesitaremos destaca el correo electrónico. Se ha convertido en una costumbre usarlo para verificar que el usuario existe de verdad, pero eso ya se podría conseguir con un captcha o una pregunta, así que lo que se demuestra con esto es que la verdadera intención al pedir este dato es el poder comunicarnos con el usuario cuando no esté usando nuestra aplicación. O, dicho de otra manera, intentar forzarlo a que la use en todo momento.
¿Cuál es el problema de este método? Pues que los usuarios hemos aprendido de esta táctica rastrera y, hartos de ella, hemos optado por soluciones como tener una segunda cuenta para recibir todo el spam procedente de registros, o incluso acudir a cuentas de correo temporales, con tiempos de caducidad muy cortos, como la exitosa 10 Minute Mail que nos permite recibir e incluso contestar a correos (aunque no redactar mensajes nuevos, para evitar que nosotros seamos los spammers amparados en el anonimato).
En definitiva, por encabezonarnos en pedir un dato que probablemente no necesitamos, obtenemos lo que nadie quiere en sus BBDD: datos falsos o incorrectos. E igualmente ocurre con otros datos típicos: ¿para qué quieres conocer mi código postal si no me vas a enviar nada? Aparte de para tus estadísticas, ¿te sirve de algo saber si soy hombre o mujer? ¿Qué interés tienes en conocer tres de mis hobbies, aparte de, por supuesto, madarme spam sobre ellos?
¿Quiénes son mis usuarios? ¿Tienen alguna particularidad? ¿Y mi proyecto?
Si en el apartado anterior hablábamos de las características generales que nos sobran a menudo, ahora trataremos las características específicas que pueden faltar o sobrar dependiendo del público objetivo al que vaya dirigida la aplicación.
La edad, por ejemplo, puede ser un dato necesario si nuestra aplicación tiene ciertos contenidos que no sean aptos para todos los públicos. La teoría de base de datos nos enseñó que se deben guardar datos invariables como la fecha de nacimiento en lugar de la edad, que inevitablemente cambiará año tras año. Sin embargo, como decíamos antes, el usuario ya desconfía y el hecho de que le pidas la fecha de nacimiento le hará pensar que quieres enviarle spam en forma de felicitación de cumpleaños. Una forma bastante simple de recabar este dato que necesitamos sin asustar al usuario es simplemente preguntarle si es mayor que la edad mínima legal para acceder a tus contenidos.
A veces una perspectiva excesivamente localista nos impide identificar otros posibles focos de problemas. Poner como obligatorio el segundo apellido, por ejemplo, hará que muchos extranjeros no puedan pasar el formulario, especialmente si en ese campo incluimos un validador que impida valores no alfabéticos como un punto o un guión. Lo mismo puede ocurrir con otros conceptos que no existan fuera de nuestro país, como el DNI, la comunidad autónoma, el código postal…
Por eso es importante especificar en un primer momento (mediante escenarios o casos de uso), quiénes van a ser nuestros usuarios, qué particularidades tienen y qué datos son realmente imprescindibles. Además, tenerlos bien definidos nos ayudará a pasar con facilidad los controles de los departamentos legales del cliente, o de quien se encargue de controlarlos. No hay que olvidar que la LOPD es de cumplimiento obligatorio y que ante la recolección de ciertos datos sensibles será necesario instalar mayores medidas de seguridad.
¿Me conviene permitir un registro rápido mediante un login externo?
Últimamente están muy de moda las opciones de identificarse o incluso registrarse mediante servicios como Facebook connect, Sign in with Twitter, OpenID, Oauth, etc. Estos conectores son una opción bastante rápida para evitar que nuestros visitantes se aburran rellenando un formulario interminable, pero también tienen sus riesgos.
Por una parte, la dependencia de un tercero siempre introduce un riesgo o incertidumbre en nuestro sistema. Puede que nuestra aplicación tenga apenas 100 usuarios, pero muy fieles, lo cual no sería problema alguno para nuestro servidor, pero que por culpa de una caída de Twitter, totalmente ajena a nosotros, no puedan conectarse a nuestra aplicación.
Además, según la cantidad de datos que queramos recabar de nuestros registrados por medio de la aplicación externa, es más probable que se muestren reacios a compartir sus datos, ya que en esos entornos no sólo tienen su información “formal”, sino también su información privada acerca de relaciones personales. Sirva como ejemplo la siguiente muestra de datos que puede leer o modificar una aplicación para marcar nuestro ritmo mientras corremos.
Por último, hay que ponerse en el lugar del usuario y entender que usar un mismo login para todas sus aplicaciones conlleva un riesgo para él, ya que si la contraseña cae en malas manos el ámbito de actuación del atacante será mucho mayor, y por lo tanto el perjuicio para nuestro inocente usuario.
Eficiencia y pasos del proceso
Cuando por fin tenemos claro qué queremos saber del usuario y cómo queremos solicitárselo, llegamos por fin a la implementación. En este punto es importante no agobiarle con un formulario tan kilométrico como este artículo, pero tampoco paginarlo en veinte secciones haciendo que el uso del ratón suba exponencialmente. Hay que huir tanto del scroll como del exceso de clics.
Aparte de una buena distribución, conviene anteponerse a los posibles errores: controlar o incluso impedir la introducción de valores no válidos, avisar sobre la disponibilidad del nombre de usuario en cuanto el textbox pierda el foco, usar máscaras que aclaren al usuario en qué formato introducir los datos, acompañar de textos de ayuda las opciones menos convencionales, etc. AJAX y JavaScript son dos herramientas fundamentales en esta fase para facilitar la velocidad del proceso.
Finalmente, si conseguimos que el usuario haya pasado este proceso de forma poco traumática, verá nuestra aplicación con mejores ojos, aunque esto no nos puede garantizar el éxito ni el fracaso de la misma. Como decíamos, en este punto ha pasado el umbral de nuestra puerta, y ahora es cuando nos toca enseñarle la casa y esperar que le guste.
