Técnicas y metodologías de optimización de la experiencia del usuario

La división de casos complejos en casos hijo más pequeños y manejables, es decir, el patrón de dividir para reinar, le permite procesar cada caso hijo de forma independiente. Esta técnica evita cargar un único caso grande en la sesión del usuario. Esta técnica se utiliza, por ejemplo, en aplicaciones de servicio de campo, por ejemplo, el caso padre representa el problema general que debe abordarse. Luego, los casos hijo se separan para registrar el trabajo realizado por los técnicos.

La carga de un único formulario complejo en la sesión del usuario puede impactar en el rendimiento. Diseñe la interfaz de usuario para permitirle al usuario enfocarse en completar una tarea específica. Las técnicas incluyen:

• Dividir formularios complejos en módulos lógicos que permitan a los usuarios concentrarse en una meta inmediata.
• Usar layout groups para dividir formularios largos en grupos lógicos.

Una vez que el formulario esté dividido en layout groups, diseñe cada layout group para usar la función de carga diferida. Este enfoque permite que los datos del layout group se carguen cuando se carga el formulario. Los datos de los otros layout groups se cargan dinámicamente cuando los usuarios seleccionan cada layout group en el navegador.

La carga diferida de datos puede mejorar notablemente el rendimiento percibido de una interfaz de usuario. Se representa la pantalla casi inmediatamente a través de un procesamiento asincrónico o en segundo plano, lo que permite al usuario seguir con la tarea en cuestión. Al mismo tiempo, se recupera información adicional que se muestra a medida que está disponible. Use la opción de carga diferida en diseños dinámicos para mostrar contenido secundario.

Use las páginas de datos como fuente para los controles basados en listas. Las páginas de datos actúan como un origen de datos en caché cuyo alcance se puede delimitar, que se puede invalidar en función de los criterios configurados y se puede recopilar como elementos no utilizados.

Pega Platform proporciona varios mecanismos para ejecutar el procesamiento en paralelo o de forma asíncrona cuando se integra con sistemas externos. Por ejemplo, puede iniciar una llamada a un sistema de back-end y continuar su procesamiento sin bloquear y esperar la respuesta del sistema externo. Este método es útil cuando el tiempo de procesamiento del sistema externo puede ser largo y cuando el resultado del procesamiento no se necesita de inmediato.

Imagine el siguiente escenario. En una aplicación de reclamos, recupera los datos y las políticas de los clientes que llaman para presentar un reclamo. Los datos se recuperan mediante dos conectores: GetCustomerData y GetPolicyList. Para acelerar la carga de datos de clientes, ejecute los conectores en paralelo.

Puede usar la opción Run in Parallel (Ejecutar en paralelo) en el método Connect (Conectar) para lograr esto. En este caso, cada conector se ejecuta como un solicitante secundario independiente. La actividad de llamada, el solicitante principal, retiene el control de la sesión y no tiene que esperar a que cada conector, en sucesión, reciba su respuesta. La función Run in Parallel (Ejecutar en paralelo) es útil cuando se pueden realizar tareas posteriores mientras se espera que varios conectores recuperen sus respuestas. Cuando la llamada de servicio se ejecuta en otro solicitante, los usuarios no esperan a que finalice la llamada de servicio y pueden continuar con otras tareas.  

Imagine el siguiente escenario. Tiene un conector SOAP denominado UpdateCustomerData que actualiza un registro de cliente en un sistema externo. La respuesta devuelta por el servicio es irrelevante para el procesamiento posterior. Debido a que otras aplicaciones pueden bloquear temporalmente al cliente, vuelva a intentar la ejecución si falla.

Además de ejecutarse de forma síncrona y en paralelo, los conectores SOAP, REST, SAP y HTTP también se pueden ejecutar en modo de cola. Seleccione queueing  en la sección Processing Options (Opciones de procesamiento) en la pestaña Service (Servicio) del registro del conector para configurar la cola.

Cada solicitud se pone en cola y luego un agente o procesador de cola la procesa en segundo plano cuando se usa. La próxima vez que se ejecute el agente o el procesador de cola asociado con la cola, se intentará ejecutar la solicitud. Las características de la cola se definen en el procesador de solicitudes del conector.

El procesamiento en segundo plano también se puede aprovechar para permitir que se cargue una pantalla inicial. Al hacerlo, el usuario puede continuar trabajando mientras se recupera información detallada adicional. Esta estrategia es beneficiosa cuando se usa el patrón de diseño SOR.

La paginación se puede aprovechar para permitir que los reportes de ejecución prolongada recuperen la información suficiente para cargar la primera página del reporte. A medida que el usuario se desplaza hacia abajo para ver el reporte, se recuperan registros adicionales y se muestran a medida que se necesitan. Use la configuración de paginación adecuada en cuadrículas y repita dynamic layouts para reducir el marcado utilizado en la UI.

Use dynamic layouts repetitivos para listas no tabulares. Evite varios dynamic layouts repetitivos anidados.

Asegúrese de que las múltiples acciones que se procesan en el servidor estén agrupadas para que solo haya un único servicio de ida y vuelta.

Cuando sea posible, use expresiones, cálculos y validaciones del lado del cliente en vez de expresiones, cálculos y validaciones del lado del servidor. Siempre que las expresiones, cálculos y validaciones puedan ejecutarse del lado del cliente, lo hacen en el navegador. Generalmente, este escenario se da en expresiones usadas para condiciones de visibilidad, condiciones deshabilitadas y condiciones requeridas, y en las expresiones de declaración que hacen referencia a propiedades editables en el formulario.

Utilice contenedores dinámicos de una sola página que no sean iFrame (sin iFrame), ya que son mucho más ligeros en el navegador, permiten un mejor diseño y una interacción similar a la de la web.

Solo incruste secciones si realmente están destinadas a su reutilización. Pega Platform copia la configuración de las secciones incluidas en las secciones en las que están incluidas. Para hacer referencia a una sección, es más simple arrastrar y soltar la sección en una celda.

Use la actualización de la sección en lugar del arnés de actualización para actualizar solo lo que se requiere en un formulario. Para reducir el marcado, use la configuración basada en código optimizado en la pestaña de dynamic layouts Presentation .

Las alertas de PEGA0001 normalmente ocultan otros problemas de rendimiento subyacentes que pueden afectar de forma negativa la experiencia del usuario. Aproveche una de las herramientas de rendimiento proporcionadas por Pega, como AES o PDC, para identificar el problema de rendimiento subyacente. Una vez que haya identificado la causa del problema de rendimiento, rediseñe e implemente una solución para abordar el problema.

Algunos ejemplos de alertas que están detrás de los mensajes de alerta PEGA0001 son:

• PEGA0005: el tiempo de consulta supera el límite.
• PEGA0020: el tiempo total de interacción de conexión supera el límite
• PEGA0026: el tiempo para conectarse a la base de datos supera el límite.

Aproveche todas las tecnologías más recientes de Pega Platform para obtener un mejor rendimiento del lado del cliente y un marcado menor. La última tecnología de interfaz de usuario es HTML 5 y CSS 3.0.

Aproveche las fuentes de íconos y los nuevos menús. Use la menor cantidad posible de diseños y controles, y utilice siempre los últimos componentes y configuraciones.

Use layouts de pantalla, layout groups, dynamic layouts, contenedores dinámicos y dynamic layouts repetitivos. Evite el acordeón heredado, la repetición de columnas, la repetición con pestañas y las tablas de forma libre, ya que se ejecutan en modo peculiar. Use layout groups en lugar de pestañas heredadas, que han quedado obsoletas. Además, evite los estilos en línea (no son recomendados, aunque aún están disponibles), los layouts inteligentes y los conjuntos de paneles.

Pega Platform proporciona una interfaz de usuario robusta y configurable para sus aplicaciones de Pega, así como una funcionalidad de mashup que puede usar para incorporar marcos de Pega en su aplicación que no es de Pega. Además, Pega proporciona API REST que puede usar para completar su interfaz de usuario que no es de Pega con los resultados de las reglas de Pega. Cuando utiliza las API REST de Pega, los usuarios de su aplicación acceden a la funcionalidad de negocio de Pega en una interfaz familiar.

Estas API REST se conocen como API de experiencia digital porque aprovechan las reglas de la interfaz de usuario de Pega Platform (arneses y secciones) junto con las reglas de negocio de Pega para devolver estructuras equivalentes a JSON que puede representar con su interfaz nativa.

Para obtener más información sobre el uso de Digital Experience API para diseñar pantallas personalizadas, consulte Creación de pantallas personalizadas con Digital Experience API.

Evite las siguientes prácticas de diseño:

• Uso incorrecto de controles de lista
• Desarrollo paralelo no coordinado

El uso incorrecto de los controles de lista es un problema común y se puede evitar fácilmente durante el diseño de una solución. Configure los controles de autocompletar para obtener datos de páginas de datos que nunca devuelven más de 100 filas de datos. Limite los cuadros de lista desplegable a no más de 50 filas de datos.

Los controles de autocompletar afectan negativamente la experiencia de usuario si:

• El conjunto de resultados potenciales es mayor a 100 filas.
• Todos los resultados de la lista comienzan con los mismos tres caracteres.

Reduzca el tamaño del conjunto de resultados para todos los controles de lista tanto como sea posible. Si el tamaño del conjunto de resultados tiene más de 100 filas para una función de autocompletar, 50 filas para una lista desplegable o siete filas para radio buttons, use un componente de UI o un mecanismo de búsqueda de datos diferente. Siempre tome los controles de lista de las páginas de datos. Considere la posibilidad de cargar las páginas de datos utilizadas para controlar la lista de origen de forma asincrónica.

Los esfuerzos de desarrollo paralelo no coordinados también pueden afectar de forma negativa el rendimiento para el usuario. Por ejemplo, varios equipos de desarrollo podrían invocar el mismo servicio web y devolver el mismo conjunto de resultados varias veces y con segundos de diferencia. Si varias llamadas de servicio devuelven el mismo conjunto de resultados, se desperdician ciclos de CPU y memoria. Para evitar esta situación, diseñe una estrategia para que los equipos de desarrollo coordinen las llamadas al servicio web mediante páginas de datos compartidos.