Modelos de Colaboração para ArcGIS Online

PeterKnoop

A intenção deste post é fomentar a discussão sobre as expectativas dos usuários para colaboração e como o ArcGIS Online pode melhor atender a essas necessidades. Não se trata de compartilhar ou buscar soluções alternativas para as limitações e circunstâncias atualmente impostas pelo sistema. 

Tipos

Geralmente, os usuários buscam realizar dois grandes tipos de colaboração no ArcGIS Online: 

1. Parceria de iguais
2. Comunidade de disseminação

No primeiro caso, os membros da colaboração concordam em tratar uns aos outros como iguais e compartilhar a responsabilidade pela colaboração. Quando compartilham informações na colaboração, podem escolher compartilhá-las com acesso total (full-control) ou apenas visualização (view-only) concedido aos seus colegas colaboradores.

Ao compartilhar com full-control, esperam que os colaboradores possam fazer qualquer coisa com a informação, independentemente de quem originalmente a criou ou a autoria. Ao compartilhar com view-only, a expectativa é que os colegas colaboradores possam apenas visualizar a informação, sem modificá-la.

Inerente ao modelo está a expectativa de que, à medida que pessoas entram e saem da colaboração, isso não impacta a capacidade dos colaboradores de interagir com os itens que foram compartilhados com full-control concedido à colaboração. Em outras palavras, a colaboração "possui" o conteúdo, e não qualquer usuário individual. 

Se alguém sai de uma organização, esperada ou inesperadamente, isso não deve impactar o conteúdo das colaborações nas quais participa. Seus colegas colaboradores esperam poder continuar com o trabalho normalmente, sem precisar fazer nada extra.

No segundo caso, uma comunidade de disseminação, a colaboração frequentemente abrange dois níveis de usuários. Um nível espera operar no estilo parceria de iguais, enquanto o segundo nível pode apenas visualizar informações. 

Esse segundo tipo de colaboração geralmente representa uma etapa posterior em um fluxo de trabalho que começa com o primeiro tipo de colaboração. Uma pequena equipe central, trabalhando como iguais e colaborando em informações, chega a um ponto onde deseja disseminar um subconjunto dessas informações para uma comunidade, buscando seu feedback e revisões, mas sem permitir que modifiquem as informações.

Existem variações nesses dois tipos de colaboração; entretanto, são menos prevalentes. O suporte para casos extremos não deve comprometer o suporte para os dois casos mais comuns por meio de uma experiência do usuário simples e intuitiva.

Gerenciamento

Os usuários esperam poder participar de ambos os tipos de colaborações por conta própria. Aqueles que participam como iguais esperam ter controle total e igualitário sobre criar, atualizar e excluir a colaboração.

A escalabilidade é crucial para grandes organizações, e nenhuma solicitação ou intervenção manual por parte de outros, como administradores do sistema, deve ser necessária para gerenciar essas colaborações.

Usuários

Muitos usuários da moderna Plataforma Esri ArcGIS são novos no ArcGIS. A maioria não são Profissionais GIS no sentido tradicional do GIS desktop. Eles vieram para o GIS pelas ferramentas web GIS leves, como Map Viewer, StoryMaps, Survey123, Collector etc. 

Esses usuários frequentemente trabalham colaborativamente em projetos, em vez de sozinhos. 

Corolários

As expectativas dos usuários em relação à colaboração foram definidas por suas experiências com outros sistemas envolvidos em seu trabalho diário; sistemas que provavelmente usam com mais frequência do que o ArcGIS Online. Quando o ArcGIS se desvia significativamente dessas normas estabelecidas, deve ter uma razão muito boa. Caso contrário, corre o risco de preparar os usuários para falhas e elevar desnecessariamente a dificuldade para aprender o sistema, o que pode ser frustrante e desencorajá-los a usar o sistema.

Sistemas como soluções organizacionais de compartilhamento de arquivos, suítes de produtividade, Sistemas de Gerenciamento de Conteúdo (CMS), Sistemas de Gerenciamento de Aprendizagem (LMS) e outras soluções SaaS estão definindo expectativas para colaboração. Esses são os sistemas que os usuários utilizam diariamente para colaborar, tais como: Google Apps, Office 365, DropBox, Google Drive, OneDrive, Box, Canvas, Blackboard, WordPress e mais....

Afinal, no seu núcleo, o ArcGIS Online é um sistema de gerenciamento de conteúdo, como o Google Drive. Sobreposto a isso estão apps como Map Viewer, StoryMaps, Field Maps, Survey123, Experience Builder, Insights, Hub etc., assim como os apps do Google sobre o Drive: Docs, Sheets, Slides, Forms, Gmail, Calendar, Sites, Maps, Earth etc.

Esses outros sistemas ancoram a colaboração nos itens do sistema permitindo que os usuários compartilhem itens com usuários individuais e/ou grupos. Também suportam compartilhar um item de múltiplas formas para diferentes combinações desses usuários individuais e/ou grupos.

Muitos desses sistemas também tratam a organização do conteúdo separadamente do compartilhamento do conteúdo permitindo que usuários em uma parceria de iguais co-organizem conteúdo dentro da colaboração (por exemplo: Google Team Drives).

Atender à maioria dos usuários modernos de GIS com familiaridade em torno da colaboração significa poder aproveitar a intuição deles reduzindo a necessidade de treinamento e acelerando o trabalho. Profissionais GIS engajados em colaboração também não serão desacelerados pois eles também usam muitos desses mesmos sistemas para as partes não-GIS do seu trabalho e podem aproveitar sua experiência existente.

Casos de Uso

Embora não explicitamente declarado em todos os casos abaixo há uma expectativa implícita que qualquer combinação de "usuários" (ou seja: professores (faculty), funcionários (staff), estudantes e outros colaboradores) — provenientes de uma ou mais organizações ArcGIS Online — possam estar igualmente envolvidos numa colaboração sem esforço extra. Usuários também podem sair ou entrar numa colaboração sem impacto adverso na mesma.

• Um projeto de pesquisa utilizando ArcGIS Online onde todos os usuários têm responsabilidade igual pelo conteúdo da colaboração.
• Um projeto de pesquisa em que um grupo tem trabalhado junto no ArcGIS Online e agora quer compartilhá-lo com um grupo maior conhecido para revisão.
• Um projeto de serviço comunitário no qual um grupo está trabalhando onde todos têm responsabilidade igual pelo conteúdo e agora querem compartilhá-lo com partes interessadas da comunidade para feedback.
• Uma tarefa acadêmica onde um instrutor compartilha alguns mapas e camadas apenas para visualização fornecendo aos estudantes informações contextuais ou antecedentes para incorporar na tarefa.
• Uma tarefa acadêmica onde um instrutor compartilha camadas editáveis fornecendo aos estudantes um ponto inicial para sua tarefa
• Um projeto em grupo onde estudantes trabalham juntos num StoryMap, Web Map (Mapa Web), Feature Layers etc., pelos quais todos têm responsabilidade igual.
• Um projeto em grupo no qual estudantes trabalharam juntos e agora precisam compartilhá-lo com seus colegas para revisão por pares.
• Um projeto em grupo no qual estudantes trabalharam juntos e agora precisam entregar o projeto (todos os seus componentes) ao instrutor; o projeto em si ou um clone completo dele que o instrutor está revisando não deve mais ser editável pelos estudantes após a data limite do projeto.
• Um projeto finalizado que um grupo deseja compartilhar apenas para visualização com sua organização ou publicamente.
• Um projeto de pesquisa ou tarefa acadêmica onde usuários têm diferentes níveis de responsabilidade entre colaborações dentro de uma colaboração maior; alguns usuários têm controle total em algumas colaborações; alguns são participantes somente leitura em outras; e/ou alguns não estão envolvidos em todas as colaborações.

Estado Atual

Embora o ArcGIS Online esteja próximo de suportar ambos os tipos de colaboração a experiência atual coloca obstáculos desnecessários no caminho dos usuários; não se baseia nas expectativas nem na intuição dos usuários; além disso impõe uma carga irrealista aos administradores do sistema. 

Por exemplo: um Shared Update Group faz quase tudo que uma parceria entre iguais precisa mas não pode ser facilmente criado pelos próprios usuários. De forma semelhante um Grupo regular realiza grande parte do que uma comunidade de disseminação requer mas está inesperadamente centrado no grupo ao invés do conteúdo. 

Juntos ambos os tipos de grupos fornecem algumas das peças necessárias quando você tem uma equipe central igualitária que posteriormente precisa disseminar informações para um grupo maior revisar; ou quando você tem uma grande colaboração abrangendo várias colaborações menores sobrepostas. A experiência atual porém está novamente centrada nos grupos ao invés do conteúdo ser o foco.

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.