Servidores de portales: ¿usabilidad empaquetada?

El navegador consume gran parte de nuestro tiempo frente a una pantalla de ordenador.

En entornos intranet, la digitalización de contenidos y su gestión, la migración de aplicaciones "legacy" y la creación de nuevas aplicaciones en formato web nos llevan casi irremediablemente al desarrollo de Portales como punto único de arranque de la sesión de trabajo de los empleados de muchas grandes empresas.

Infodump: publicación o vertido

En el estado del arte del mundo intranet, es común una frase dicha por los promotores del uso de las intranets sus empleados: "todo está en la intranet". En un mundo ideal esta frase podría ser una bendición. Nada más lejos de la realidad:

Desintegración: la mayor parte de las intranets nacen de iniciativas departamentales espontáneas. Se crean por un equipo de personas con conocimientos técnicos que habilitan un servidor web dentro de la red. Las intranets nacen bajo la premisa "Un departamento una intranet".

Esto trae varias consecuencias: primera, no existe arquitectura: dificultad de saber cuántas intranets existen en la compañía (departamentales, locales, funcionales…); segunda, estas intranets residen en sistemas diferentes, por lo que se producen limitaciones que afectan directamente a la Experiencia del Usuario: apertura de nuevas ventanas, necesidad de identificarse varias veces; tercera, aspecto de "traje de payaso", cada sección, cada portal tiene un aspecto y unos "recursos" gráficos diferentes no estandarizados.

Desestructuración: Archivos html, pdfs, documentos office, bases de datos… La información reside desestructurada, dispersa y duplicada en multitud de equipos existentes en redes corporativas.

Intranet vertedero: Lo promoción del uso de la intranet se basa en estrategias inadecuadas: se vuelcan contenidos en servidores web sin orden ni criterios de catalogación.

Buscadores que no encuentran: el carácter disperso y desestructurado de la información y la carencia de método y orden en el mantenimiento, lleva a que los buscadores no sean fiables. Encontrar algo se convierte en una tarea imposible cuya solución es solicitar el envío de información por correo electrónico.

Poniendo orden

En muchas organizaciones hace tiempo que se han dado cuenta de la necesidad de gestionar contenidos y servicios presentes en su intranet, lo que les ha llevado directamente a hacer inversiones en Gestores de Contenidos (CMS) y en sistemas de gestión documental.

Los CMS, permiten la fácil recolección, gestión y publicación de los contenidos, (gestión del "Ciclo de Vida del Contenido") desde un punto único centralizado.

Por otro lado, las empresas comienzan desarrollar sus aplicaciones de negocio en formato web y a migrar todas las existentes a este formato, poco adecuado como entorno de trabajo.

Aplicaciones, documentos, contenidos, comunicaciones,… si a esto añadimos la ofimática como herramientas de trabajo, tenemos una clara visión de hacia donde evoluciona el tándem navegador-intranet. Frente a su uso anecdótico actual, este duo tratará de superponerse al Escritorio del sistema operativo convirtiéndose en un entorno de comunicación y productividad en sí mismo similar a un sistema de acceso a recursos compartidos.

Para dar este salto surgen los Enterprise Portals soportados por una herramienta denominada Servidor de Portales o Portal Servers.

Portalización

¿Qué es un Enterprise Portal? Un portal es una aplicación con las siguientes características:

• Basado en web: servidor web y cliente navegador
• Personalizable
• Single sing-on: existe una integración de sistemas que permite un punto de identificación único para cada usuario.
• Agregación de contenidos de diversas fuentes

Existen productos en el mercado denominados Servidores de Portales o Portal Servers cuya misión es permitir el desarrollo rápido de portales que integran el acceso a información, servicios y aplicaciones. Se generan a través de portlets o componentes de presentación.

¿Qué es un portlet?

Son componentes web gestionados por un contenedor que tras la petición de un usuario generan y presentan contenidos dinámicos de forma identificable en el interfaz de usuario del portal como componentes de contenido. El portlet permite la personalización, la presentación, y la gestión de la seguridad. Los portlets se diferencian de los servlets por ser estos componentes de servidor con perspectiva funcional.

El concepto de portlet es propio del mundo Java, y tiene su traducción en el entorno Microsoft como "web parts". (Sharepoint Portal Server)

Según la Java Specification Request 168 y la WSRP (Web Services for Remote Portals), que tratan de definir los estándares para el desarrollo de portlets y su interoperabilidad, son componentes web basados en Java, y gestionados por un contenedor de portlets que procesa peticiones y genera contenido dinámico. Los portales usan portlets como componentes de interfaz de usuario que proveen de una capa de presentación a los sistemas de información.

Ejemplos típicos de portlets preconfigurados pueden ser noticias provenientes de un CMS, email, cotizaciones, metereología, foros, encuestas, formularios, canales RSS, WebServices, integración de aplicaciones, herramientas de análisis, herramientas de trabajo en grupo. Otros son aquellos que a través de componentes Active X o applets permiten la integracion dentro del navegador de otros programas, como clientes de correo o programas de ofimática.

Descripción de un portlet

El contenido generado por los portlets se denomina "fragmento". Es código XHTML, HTML, WML, etc. Los fragmentos agregados resultantes de la operación de varios portlets constituyen un documento que se traduce en el interfaz del portal. Estos elementos se disponen a través de una "retícula" o rejilla.

Retícula contenedora de fragmentos.

Cómo funciona un portlet

El portlet, al igual que los contenidos tiene su propio ciclo de vida. Los portales actúan como gestores de presentación de los portlets. Los usuarios realizan peticiones durante su sesión de navegación, y los portlets generarán contenidos dependiendo del perfil del usuario que realice las peticiones.

Según la especificación JSR 168 tiene tres fases:

• Inicio (Init): el usuario, al interactuar con el portal arranca el portlet activando el servicio.
• Gestión de peticiones (Handle requests): procesa la petición mostrando diferentes informaciones y contenido según el tipo de petición. Los datos pueden redidir en sistemas diferentes. Dentro de esta fase se encuentra la Presentación, en la que el portlet da salida a la información en formato código para su visualización en el navegador.
• Destrucción, (Destroy): elimina el portlet cuyo servicio deja de estar disponible.

Trabajar con Servidores de Portales

Ventajas

• Rapidez de desarrollo: crear un portal con un servidor de portales se hace en plazos relativamente breves.

  Los portlets recogen funcionalidades de uso frecuente y las hacen disponibles para integrarlas en un Portal. Las ventajas derivadas es que ya están generados y debido a su uso frecuente se convierten en patrones que recogen las "mejores prácticas" del mercado.

• Altas capacidades de Personalización: no se trata sólo de presentar determinados portlets a diferentes usuarios, sino también de las diversas posibilidades de presentación de informacion de cada portlet.
• Consolidación e integración de sitios dispersos: mediante un servidor de portales se centraliza la gestión de sitios dispersos ahorrando en costes de mantenimiento.
• Administración delegada: mediante un sistema de permisos se delega el mantenimiento de portales o secciones agilizando los procesos de publicación.

Algunos problemas

Como sucede con los coches, la estandarización, la madurez y la aplicación de criterios ergonómicos de muchos productos hace que al final "todos sean iguales" y su única diferencia sea precio, extras y marca. Los servidores de portales pueden caer dentro de este ejemplo: ergonómicos pero mecánicos e impersonales.

El concepto de Portlet llevado a su máxima expresión puede hacernos caer en la trampa de que un Portal no es más que una agregación de portlets, descuidando otros aspectos básicos menos evidentes:

• Mecanización y despersonalización del diseño: la traslación más evidente del Portlet a un interfaz de usuario son las "cajitas", que le otorgan ese aspecto "nukeado" impersonal y aestético. El dejar que sea el portlet quien controle el aspecto final del portal puede repercutir en una despersonalización de la imagen de la compañía.
• La rapidez en el desarrollo puede resultar una desventaja … cuando no se tienen unos objetivos claramente definidos. Decidirse por una herramienta de este tipo, simplemente, porque es rápida de desarrollar e instalar puede ser perjudicial y favorecer desarrollos sin visión estratégica.
• Pérdida de perspectiva de usuario: el sistema permite que una persona con conocimientos, a través de un checklist y una rejilla decida "cómo va a ser un portal". Algo que es una ventaja puede convertirse en un problema si los responsables de desarrollo de ese portal no adoptan el punto de vista del usuario y sus necesidades reales.

Cuestiones abiertas

Hace no mucho tiempo escuché a una persona relacionada con el mundo web decir que "la usabilidad tenía los días contados con la aparición de Portales in-a-box" y otros productos empaquetados.

El diseño centrado en el usuario vive tranquilo cuando arquitectura, procesos, diseño… todo está por definir. Estos productos están muy definidos y plantean varias cuestiones:

• ¿Son los productos empaquetados una amenaza para la definición de servicios web?
• ¿Son los productos empaquetados una amenaza para la usabilidad?
• ¿Son los productos empaquetados una amenaza para el diseño y la creación de imagen de marca?
• ¿Nos dirigimos a crear experiencias uniformes no importa que sector, no importa que compañía?
• ¿Cuáles serán los elementos diferenciadores ante la uniformidad?

En conclusión… ¿Hacia dónde evolucionará el perfil de los equipos de interfaz de usuario, (consultoría de usabilidad, diseño y desarrollo de plantillas), con la adquisición de estos productos por muchas compañías? Renovarse o morir.