Definir el “usuario” a la hora de crear una aplicación web es todo un arte. Miles de sesudas cabezas han incluso intentado convertirlo en una ciencia creando teses de usuario para definir la usabilidad de una aplicación, metodologías ágiles definiendo backlogs mediante historias de usuario, técnicas SEO que convierten a Google en nuestro principal usuario, maquetación responsive porque nuestro usuario utiliza móviles y tabletas…
Pero hay un usuario del que casi todos se olvidan. El día a día de una aplicación web requiere de él, el administrador. Y la verdad es que en el backend de las aplicaciones web, feudo de programadores hardcore, el cariño a este usuario, históricamente, ha brillado por su ausencia.
A mi particularmente, es un “usuario” que me preocupa especialmente, porque si para él es complicado el manejo de la administración, difícil técnicamente, costoso en tiempo… dejara de hacer su trabajo o no lo hará con tanto “cariño” y eso provocará que todo el esfuerzo gastado en “los otros usuarios” se vaya al garete.
Como mejorar la experiencia del “usuario” administrador de un sitio web. Un ejemplo con Liferay.
Como desarrolladores backend existen varias campos en los que podemos trabajar para hacer la vida más fácil a nuestro “usuario”, muchas de ellas comunes a otros CMS‘s o aplicaciones hechas a medida, pero dado que últimamente estoy trabajando mucho con Liferay me centraré en este CMS en particular.
- En lugar de usar el tipo de contenido básico y darle funcionalidades distintas con categorías, etiquetas, etc… genera tipos de contenido (estructuras) que sean más intuitivos de usar. Si esto no es posible “crea tu mismo” la base de categorías y una política de etiquetas clara. Tu tienes más experiencia en estas lides que el “usuario”.
- Si puedes, define estructuras y pásate un buen rato pensando como hacer le vida sencilla al “usuario”:
- Incluye desplegables con opciones en lugar de campos de texto que el “usuario” tenga que recordar y rellenar manualmente.
- Piensa bien el tipo de campos que vas a usar. Haz uso de campos repetibles, multiselección, fecha, booleanos, etc…
- Evita el mayor número de campos posibles. No incluyas campos porque te facilitan la programación a costa de hacer trabajar al “usuario”.
- Al definir estas estructuras no te quedes en el asistente. Hackeando un poco el XML de la definición podrás:
- Introducir nombre de los campos que no sean los de la variable que usuarás en la programación. El good naming no es solo cosa del Clean code o locos del UX o SEO. Podrás dar un nombre a ese campo que tendrá sentido para el “usuario”.
- Si gastas un poquito más de tiempo incluso podrás proporcionar ayudas en forma de TIP que le ayudará a realizar su trabajo.
- Define campos por defecto en las estructuras:
- Si para que sea más fácil buscarlo en la intranet los contenido web van a llamarse todos “MEMORANDUM xxx” eso debería estar relleno por defecto al crear un nuevo contenido basado en nuestra estructura.
- Si la aplicación es multi-idioma preselecciona los que habitualmente serán traducibles, pero solo esos. Si por ejemplo nuestra estructura tiene una imagen, haz que por defecto esta no sea traducible (normalmente no lo será), así no tendrá que meterla dos veces o volver atrás a deschequear ese campo cuando ya ha comenzado a traducir.
- Si tu aplicación va a hacer uso de categorías y etiquetas, preseleccionalas.
- Liferay permite que el “usuario” componga la página a su gusto, pero no le cargues de trabajo obligándole a crear cada página desde cero.
- El Theme define gran parte de la interfaz de la aplicación web. Así, define el Theme con el mayor número de elementos posibles. No obligues, por ejemplo, a que el “usuario” tenga que introducir las migas de pan en cada nueva página que genere.
- Para todo aquello que no abarca el Theme define plantillas de página. Rómpete la cabeza determinando “tipos de página” y elementos comunes de estas. Define tantos tipos de página como sean necesarios (incluso, si no van a confundir al “usuario”, define el mismo tipo de página con distintos nombres para que sea más fácil de seleccionar el correcto en cada circunstancia). Que el “usuario” solo tenga que elegir que tipo de página quiere crear y le asigne el contenido web correspondiente (del menú relacionado, el modulo de banners, el portlet de twitter ya te has encargado tú).
- Genera portlets “inteligentes”, que se adapten a su entorno en lugar de requerir configuraciones complicadas o sencillas.
- Añade un poco de javascript extra a tu Theme para que las páginas, por ejemplo, con enlaces a contenidos externos se abran en ventana nueva sin que el “usuario” tenga que hacerlo.
- Trabajate los css’s de tu Theme para que las tareas de maquetación del “usuario” sean más sencillas.
Colofón y/o autobombo
Uno de los mayores piropos que recibí hace años de colegas de profesión fue “Mólan vuestras intranets… están muy curradas“. Y esto no es fruto de la casualidad o de la cabezonería de un par de locos, en Adimedia a todo programador que entra a trabajar se le “obliga” a leer el “No me hagas pensar” antes de hacerle mirar nuestros frameworks de trabajo.
Aveces lo hacemos mejor o peor, pero lo que si esta asegurado es que pensaremos en ese “usuario” porque normalmente no tendrá poder de decisión para contratar otros servicios, no será el que recoja los premios, pero tengo bastante claro que es uno de los más importantes para el buen funcionamiento de una aplicación web.
