El ecosistema de InfoPath o “La Oficina sin papeles”

Introducción

Hay una enorme demanda de conversión de formularios en papel a formularios electrónicos. Al utilizar el término "en papel" lo que se quiere decir es cualquier formulario que es llenado a mano y enviado a través de alguno de las siguientes maneras:

• Entrega en mano
• Fax
• Un correo electrónico con el formulario adjunto como un documento digitalizado.
• Formulario preimpreso.

A propósito de esto, casi todos los pdf en uso hoy en día entran en esta categoría. La razón no es que Adobe no tiene un adecuado proceso para formularios electrónicos, ya que Adobe lo hace. Pero Adobe no ha sido tan exitoso como Microsoft en la participación de la comunidad para utilizar su suite. Este post no es acerca de la comparación de herramientas, pero si para resaltar que es allí donde es significativamente más que un formulario, el formulario en sí.

En el caso de InfoPath, la mayoría de los clientes vienen con la esperanza de convertir un formulario en papel a formato electrónico. Mucha gente piensa que esto es un asunto trivial. Debería serlo, pero hay una gran variedad de expectativas justificables e implícitas que tienen los usuarios de formularios electrónicos que son a veces sutiles y a veces se pasan por alto. En el "El Ecosistema InfoPath" las partes constitutivas del modelo son:

1. El formulario electrónico (InfoPath)
2. Páginas de lanzamiento y de inicio
3. Presentación de informes
4. Workflows automatizados

La figura 1 ilustra el ecosistema de InfoPath.

Figura 1: El ecosistema de InfoPath

1. Los formularios electrónicos (InfoPath)

Algunas de las sutilezas que la gente no piensa cuando están convirtiendo "papel" a formularios de InfoPath son:

• Guardar vs Enviar
  En casi todos los proyectos, los clientes dicen que quieran un formulario muy sencillo. Cuando se les pregunta si que quieren la funcionalidad de “Guardar”, dicen que no y se les explica que una vez que se envía un formulario, los datos no se deben cambiar. Después el usuario comienza a trabajar con el formulario durante un tiempo, y casi todos piden agregar la funcionalidad de “Guardar” . Por “Guardar”, me refiero a que el usuario es capaz de guardar el formulario para modificaciones posteriores y los destinatarios no se notifican todavía. Además, si existen workflows automatizados que se supone que no comiencen correr, hasta que realmente se envía el formulario. Una vez que se envía el formulario, el iniciador puede volver atrás y mirar el form, pero ya no puede modificar el formulario.
• Pre-filling inteligente
  La gente tiene poca paciencia para completar formularios electrónicos. Menos aún que los formularios en papel. Consiguen frustrarse rápidamente. Por lo tanto los formularios deben completarse automáticamente con tanta información como sea posible. Por ejemplo, en un sistema donde el usuario está registrado o logeado, una gran cantidad de información personal puede ser completada. InfoPath permite añadir lógica sofisticada, que permite a muchos de los campos de formulario para ser rellenados con las respuestas más probables y además hacer conjeturas excelentes en cosas como las fechas y horas.
• Ocultar y desactivar controles inteligentemente
  Por ejemplo, el botón enviar debe ser deshabilitado, hasta que se rellenan todos los campos requeridos.
• Mostrar y ocultar partes diferentes dependiendo del usuario y el estado del formulario
  Por ejemplo, el propietario de un proceso puede tener privilegios especiales que no tienen un usuario normal. Otro ejemplo es proporcionar una página vista preliminar que muestra un resumen de todas las respuestas antes de que el usuario envía el formulario. La página de vista previa no permite editar, sólo muestra el usuario las respuestas que han dado a las preguntas del formulario. Esto es similar a la función de vista previa de impresión en muchas aplicaciones.
• Controles importantes para una experiencia fácil
  Por ejemplo, si el usuario tiene que seleccionar una respuesta de un gran número de opciones, como todas las universidades en los Estados Unidos. Un control ideal para esto es un cuadro de texto con Autocompletar.

Todo lo anterior mencionado, con excepción del último elemento, pueden implementarse por un usuario experimentado de InfoPath. El último elemento requiere un desarrollador de "nivel medio" que sabe cómo escribir Javascript, llamadas a servicios Web y jQuery (o similares).

2. Páginas de inicio
No es deseable exponer a los usuarios a una lista o biblioteca de formularios de SharePoint nativa. En la figura 2 se muestra un ejemplo de una biblioteca de forma nativa. A veces es demasiado confuso. Es una buena práctica proporcionar una página de inicio que proporciona instrucciones junto con un botón de lanzamiento. Del mismo modo esta bueno tener una página donde los usuarios pueden ver sus propios formularios. Para los formularios más simples, se puede usar una sola página como panel de control. Para los mas complejos, un panel de control mas complejo, mostrando por ejemplo los formularios en cada etapa del ciclo de vida. Un panel de control para nuevas solicitudes se puede hacer creando una página con las funcionalidades Out-of-the-box de SharePoint con un poco de html personalizado en un elemento Web Editor de contenido.

 

Figura 2: Es una captura de pantalla de una biblioteca de formularios que contiene las solicitudes . Para un usuario que empieza a conocer o usar el formulario, es hostil y confuso. Esta es la razón por la que necesitamos construir una página

3. Presentación de informes

El dueño del proceso a veces quiere ver las estadísticas de resumen de los datos. A veces piensa que es una simple lista, pero a veces viene con requisitos de un dashboard, lindos diagramas y gráficos. En este aspecto se puede ahondar bastante. Lo más sencillo es utilizar páginas de elementos Web de SharePoint con DataView WebParts , Graph Web Parts y Excel. Hay numerosos complementos de terceros que pueden permitir muy rica visualización y análisis de datos. Algunos ejemplos son: Spotfire, Tableau (herramientas de visualización) y Knime (una herramienta de código abierto que ayuda con análisis de datos.)

4. Workflows automatizados

Ya se habló de páginas de inicio para utilizar en workflows. Los Workflows para, revisores, aprobaciones, sofisticados procesos de negocios, o sólo workflows de notificaciones pueden ser difíciles de diseñar e implementar. Los workflows deben ser cuidadosamente diseñados y documentados. Generalmente se escribe un diagrama de estado tradicional. Estos diagramas de Estado se asemejan a un grafo dirigido de matemáticas (véase la figura 3.) A la hora de aplicar los workflows, hay muchas opciones. Los workflows de SharePoint Designer son una tecnología libre y te puede ayudar bastante en ciertos procesos.

El tema es cuando es necesario diseñar workflows profesionales y sobre todo sin código. En ese momento es cuando usamos Nintex Workflows que cubre el 99% de las necesidades de los usuarios.

 

Figura 3: Grafo dirigido

Conclusión

Las personas a veces hacen trivial el diseño de formularios electrónicos y no se dan cuenta que hay un importante ecosistema que se necesita para hacer los formularios más fáciles de usar, y que los resultados sean fáciles de analizar.

 

En Baufest podemos ayudarte a crear tu propio ecosistema.