Un CRUD atomizado (VI). Mejoras visuales.

En el artículo anterior hicimos una mejora programática importante. En este nos vamos a centrar más en la experiencia del usuario.

Por muy buena que sea nuestra aplicación, en Internet hay cientos de aplicaciones web que hacen lo mismo, o más, o mejor, o más y mejor. Por muy bueno que seas diseñando y desarrollando aplicacicones, siempre hay alguien mejor, o con más experiencia. Y la mayoría de las aplicaciones se enfocan, entre otras cosas, en mejorar la experiencia del usuario, para que le resulte amigable emplearlas. Es lo que se llama user friendly, según la terminología anglosajona, o usabilidad, según la adaptación al español del término.

Puede parecer una tontería mirar esos detalles. Pero seguro que tú, como usuario, prefieres una página amigable, que una página, digamos, como las que tienen las Administraciones Públicas.

En este artículo te voy a poner un par de ejemplos de cosas que podemos mejorar en nuestra aplicación. A partir de ahí, es experimentar y ver que más se te ocurre. Vamos a ello.

EL CAMPO DEL DOI

El campo del DOI (Documento Oficial de Identificación, como DNI, NIE o pasaporte) es el primero en el que tenemos que trabajar. Resulta que el usuario cumplimenta todo el formulario y sólo al final, cuando intenta grabarlo, se le informa de si el DOI está repetido. Resultaría mucho más amigable que se le informara en tiempo real, según lo está tecleando, de si está repetido o no. Para ello, le añadimos un icono a la derecha del campo. Este podrá tener tres estados posibles:

  • Un lapiz azul, si el campo está vació y aún hay que teclearlo.
  • Un check verde de aprobación, si el DOI no está repetido.
  • Un check rojo de denegación, si el DOI está repetido.

Es cierto que actualizar el estado de este icono cada vez que el usuario pulsa una tecla en el campo, aumenta el coste de procesamiento, ya que hay que estar constantemente lanzado consultas en tiempo real a la base de datos. Sin embargo, con las tecnologías actuales, el usuario no va a percibir demora alguna y, en cambio, si va a mejorar mucho su experiencia. Es un precio que merece la pena.

Programar esta operativa es fácil y rápido. En primer lugar, tenemos que hacer un pequeño retoque en la vista (member-form.component.html):

Como ves, aprovechamos las prestaciones de bootstrap para añadirle un icono asociado al campo. Además (fíjate en la línea resaltada), hacemos que las posibles clases que determinan el icono a mostrar (glyphicon-pencil, glyphicon-ok y glyphicon-remove) vengan determinadas por la lógica del componente. Ya sólo nos falta que cada uno aparezca en un color. Esto lo hacemos desde los estilos del componente (member-form.component.css), añadiendo las siguientes líneas:

En la lógica del componente tenemos que añadir el método checkDoi(), que está referenciado en la vista (línea 10), que se encargará, a su vez, de llamar a una conexión con una API para verificar si el DOI tecleado existe o no. Por lo tanto, también necesitaremos los métodos checkRepeatedDoi()checkRepeatedDoiSuccess():

Como ves en la línea 13, cuando llamamos al servicio de conexión con la API le pasamos dos parámetros: el DOI actualmente tecleado, y el id del usuarios, que, como ya sabes, será 0 en el caso de las altas nuevas. Esto es porque la API tiene que buscar el DOI en la base de datos de distinta forma si es un alta nueva o una edición.

Y esto nos lleva a aprender algo más sobre la conexión con API’s. Vamos a ver el método checkRepeatedDoi$ en http-connect.service.ts:

Sabemos que cuando hacemos una llamada por post, el primer parámetro del método post() es la API a la que llamamos, y el segundo parámetro es el valor que queremos enviar por post a dicha API. Si hay más de un valor, debemos encerrarlos entre llaves, como ves en el código. Además, este método admite un tercer parámetro. Normalmente (es el comportamiento por defecto) Angular espera la respuesta de la API en formato JSON, para procesarla en el observable. En este caso, nuestra API sólo va a devolver una S, si el DOI está repetido, o una N, si no lo está. Es decir, va a devolver una simple cadena de texto. Esto, en condiciones normales, daría lugar a un error. Con el tercer parámetro, le estamos diciendo que lo que esperamos es un texto, y ya se adapta el observable para entenderlo como tal.

CONCLUYENDO

Con estas modificaciones hemos mejorado mucho la experiencia del usuario. En el campo del nombre también hemos añadido un icono, pero esta operativa es muchísimo más simplona. No comprobamos si el nombre está repetido. Simplemente, comprobamos que haya algo tecleado- Por esta razón no me demoro en detallar el código. Con los conocimientos y experiencia que ya tienes, lo verás claro al primer vistazo. Como siempre, la aplicación, en su estado actual, te la puedes bajar en este enlace.

   

Deja un comentario