Modelos de Colaboración para ArcGIS Online

PeterKnoop

La intención de esta publicación es fomentar la discusión sobre las expectativas de los usuarios respecto a la colaboración y cómo ArcGIS Online podría servir mejor a estas necesidades. No se trata de compartir o buscar soluciones alternativas a las limitaciones y circunstancias impuestas actualmente por el sistema. 

Tipos

Generalmente, los usuarios buscan lograr dos tipos principales de colaboración en ArcGIS Online: 

1. Asociación de iguales
2. Comunidad de difusión

En el primer caso, los miembros de la colaboración acuerdan tratarse como iguales y compartir la responsabilidad de la colaboración. Cuando comparten información en la colaboración, pueden elegir compartirla con acceso de control total o solo de visualización otorgado a sus compañeros colaboradores.

Al compartir con control total, esperan que los colaboradores puedan hacer cualquier cosa con la información, independientemente de quién la haya creado o redactado originalmente. Al compartir solo para visualización, la expectativa es que los compañeros colaboradores solo puedan ver la información, no modificarla.

Inherente al modelo está la expectativa de que, a medida que las personas se unen o salen de la colaboración, esto no afecte la capacidad de los colaboradores para interactuar con los elementos que han sido compartidos con control total otorgado a la colaboración. En otras palabras, la colaboración "posee" el contenido, más que cualquier usuario individual. 

Si alguien deja una organización, ya sea esperado o inesperado, no debería afectar el contenido de las colaboraciones en las que participa. Sus compañeros colaboradores esperan poder continuar con el trabajo habitual sin tener que hacer nada adicional.

En el segundo caso, una comunidad de difusión, la colaboración a menudo abarca dos niveles de usuarios. Un nivel espera operar en el estilo de asociación de iguales, mientras que el segundo nivel solo puede ver la información. 

Este segundo tipo de colaboración suele representar un paso posterior en un flujo de trabajo que comienza con el primer tipo de colaboración. Un pequeño equipo central, trabajando como iguales y colaborando en información, llega a un punto donde desea difundir un subconjunto de su información a una comunidad para obtener retroalimentación y revisiones, pero sin permitirles modificar la información.

Existen variaciones en estos dos tipos de colaboración; sin embargo, son menos comunes. El soporte para casos extremos no debe ir en detrimento del soporte para los dos casos más comunes mediante una experiencia de usuario simple e intuitiva.

Gestión

Los usuarios esperan poder participar en ambos tipos de colaboraciones por sí mismos. Quienes participan como iguales esperan tener control total e igualitario sobre la creación, actualización y eliminación de la colaboración.

La escalabilidad es crucial para organizaciones grandes y no deberían requerirse solicitudes ni intervenciones manuales por parte de otros, como administradores del sistema, para gestionar estas colaboraciones.

Usuarios

Muchos usuarios de la moderna Plataforma Esri ArcGIS son nuevos en ArcGIS. La mayoría no son Profesionales GIS en el sentido tradicional del GIS de escritorio. Han llegado al GIS por las herramientas web ligeras como Map Viewer, StoryMaps, Survey123, Collector, etc. 

Estos usuarios suelen trabajar colaborativamente en proyectos más que individualmente. 

Corolarios

Las expectativas de los usuarios sobre la colaboración han sido establecidas por sus experiencias con otros sistemas involucrados en su trabajo diario; sistemas que probablemente usan con más frecuencia que ArcGIS Online. Cuando ArcGIS se desvía significativamente de esas normas establecidas, debe tener una muy buena razón. De lo contrario, corre el riesgo de preparar a los usuarios para el fracaso y elevar innecesariamente la dificultad para aprender el sistema, lo cual puede ser frustrante y desalentarlos a usarlo.

Sistemas como soluciones organizacionales para compartir archivos, suites de productividad, Sistemas de Gestión de Contenidos (CMS), Sistemas de Gestión del Aprendizaje (LMS) y otras soluciones SaaS están estableciendo expectativas para la colaboración. Estos son los sistemas que los usuarios utilizan día tras día para colaborar, tales como: Google Apps, Office 365, DropBox, Google Drive, OneDrive, Box, Canvas, Blackboard, WordPress y más....

Después de todo, en su esencia, ArcGIS Online es un sistema de gestión de contenidos similar a Google Drive. Encima están las aplicaciones como Map Viewer, StoryMaps, Field Maps, Survey123, Experience Builder, Insights, Hub, etc., similares a las aplicaciones de Google sobre Drive: Docs, Sheets, Slides, Forms, Gmail, Calendar, Sites, Maps, Earth, etc.

Esos otros sistemas anclan la colaboración en los elementos dentro del sistema permitiendo a los usuarios compartir elementos con usuarios individuales y/o grupos. También soportan compartir un elemento en múltiples formas con diferentes combinaciones de usuarios individuales y/o grupos.

Muchos también tratan la organización del contenido separadamente del compartir contenido permitiendo a usuarios en una asociación entre iguales coorganizar contenido dentro de la colaboración (por ejemplo: Google Team Drives).

Cumplir con la mayoría de los usuarios modernos GIS familiarizados con la colaboración significa aprovechar la intuición natural del usuario reducir la necesidad de capacitación y acelerar el trabajo. Los Profesionales GIS que colaboran tampoco se verán ralentizados ya que también usan muchos de estos mismos sistemas para las partes no GIS de su trabajo y podrían aprovechar su experiencia existente.

Caso(s) De Uso

Aunque no se indica explícitamente en cada caso abajo hay una expectativa implícita que cualquier combinación de "usuarios" (es decir: profesores personal estudiantes y otros colaboradores) —de una o más organizaciones ArcGIS Online— pueda estar igualmente involucrada en una colaboración sin esfuerzo adicional. Los usuarios también pueden salir o entrar en una colaboración sin impacto adverso sobre ella.

• Un proyecto investigativo utilizando ArcGIS Online donde todos los usuarios tienen igual responsabilidad sobre el contenido colaborativo.
• Un proyecto investigativo en el que un grupo ha estado trabajando junto en ArcGIS Online y ahora quieren compartirlo con un grupo mayor conocido para revisión.
• Un proyecto servicio comunitario donde un grupo trabaja conjuntamente teniendo igual responsabilidad sobre el contenido y ahora desean compartirlo con partes interesadas comunitarias para recibir retroalimentación.
• Una tarea académica donde un instructor comparte algunos mapas y capas solo para visualización para proporcionar a estudiantes información contextual o antecedentes para incorporar en su tarea.
• Una tarea académica donde un instructor comparte capas editables para proporcionar a estudiantes un punto inicial para su tarea
• Un proyecto grupal donde estudiantes trabajan juntos en un StoryMap Mapa Web Capas Temáticas etc., y todos tienen igual responsabilidad.
• Un proyecto grupal en el que estudiantes han estado trabajando juntos y ahora necesitan compartirlo con sus compañeros para revisión entre pares.
• Un proyecto grupal donde estudiantes han estado trabajando juntos y ahora deben entregar el proyecto (todos sus componentes) al instructor; el proyecto mismo o un clon completo del mismo que el instructor revisa ya no debería ser editable por los estudiantes después del plazo establecido.
• Un proyecto terminado que un grupo desea compartir solo para visualización con su organización o públicamente.
• Un proyecto investigativo o tarea académica donde los usuarios tienen diferentes niveles responsabilidad dentro colaboraciones dentro una colaboración mayor; algunos tienen control total en algunas colaboraciones otros son participantes solo lectura en algunas colaboraciones y/o algunos no están involucrados en todas las colaboraciones.

Estado Actual

Aunque ArcGIS Online se acerca a soportar ambos tipos colaboración la experiencia actual pone obstáculos innecesarios al camino del usuario no se basa en sus expectativas e intuición ni quita carga irrealista a administradores del sistema. 

Por ejemplo Un Grupo Compartido Para Actualización hace casi todo lo necesario para una asociación entre iguales pero no puede ser creado fácilmente por los propios usuarios. De manera similar Un Grupo regular cumple mucho lo requerido por una comunidad difusión pero está inesperadamente centrado alrededor del grupo más que del contenido. 

Ambos tipos grupos juntos proveen algunos elementos necesarios cuando tienes un equipo central entre iguales que luego necesita difundir información a un grupo mayor para revisión; o cuando tienes una gran colaboración abarcando varias colaboraciones pequeñas superpuestas. Sin embargo La experiencia actual está nuevamente centrada inesperadamente en grupos más que en hacer del contenido el foco principal.

PeterKnoop

@JeanineFinn that is a great example of how the current system doesn't meet users' expectations, and highlights how the current workaround for a partnerships of equals -- Shared Update groups -- does not scale appropriately for large organizations.

As the need for this grows in your organization, you won't have the time to create a Shared Update group for each manual request, let alone help them re-share content, if they made a regular group on their own first. Managing groups and privileges manually, at the granularity of individual users, is not scalable when you have thousands of users.

Roles are the usual approach in Software as a Service (SaaS) systems to permit you to scale the management of privileges in a reasonable way, however, you cannot do that for Shared Update groups in ArcGIS Online, without introducing automated scripts into your management practice, which defeats the SaaS expectation of minimal administration.

 

In our organization we've made the choice to head down that scripting road in order to empower all of our users with the ability to create their own Shared Update groups. We have too many users to keep detailed track of what they are doing or what they need to do in ArcGIS Online. The users themselves know best what they need, so they all have a Role which has the same privileges as the default Publisher Role, plus the privileges for Shared Update groups and Notebooks. (We have credit budgeting enabled as the mechanism for enforcing reasonable use, and we rarely have to deal with credit allocation exceptions.)

Unfortunately, the workaround is not straight-forward. The basic steps are:

1. Use Enterprise Logins.
2. Create a custom Role, say "New User", which has all the privilege you want your users to have, except the "Create with update capabilities" privilege. That privilege causes a custom role to be incompatible with New User Defaults. (Our "New User" role is based on the Publisher role, and adds the two Notebook privileges.)
3. Create another custom Role, say "Empowered User", which has the same privileges as the one above, plus the "Create with update capabilities" privilege. (You will use scripting to assign this role your users.)
4. Configure New Member Defaults to automatically assign your first custom Role, "New User", when users login the first time.
5. Run an automated script that periodically checks for users with the "New User" Role, and updates their Role to your second custom Role, "Empowered User". (We have our script scheduled to run every 5-minutes.)

You also need to perform the one-time task of updating your existing users to the that second custom Role, "Empowered Users". If you don't have too many users, then you can do this manually -- one page at a time -- in ArcGIS Online itself. If you have a lot of users, however, then I would write a quick Python script to automate the task.