Collaboration Models for ArcGIS Online

[PeterKnoop]

The intention of this post is to foster discussion regarding users' expectations for collaboration, and how ArcGIS Online might better serve these needs. It is not about sharing or seeking workarounds to the limitations and circumstances currently imposed by the system. 

Types

Generally users are looking to accomplish two major kinds of collaboration in ArcGIS Online: 

1. Partnership of equals
2. Community of dissemination

In the first case, members of the collaboration are agreeing to treat each other as equals and share responsibility for the collaboration. When they share information in the collaboration, they can choose to share it with full-control or view-only access granted to their fellow collaborators.

When sharing with full-control, they are expecting collaborators to be able to do anything with the information, regardless of who originally creates or authors it. When sharing view-only, the expectation is that fellow collaborators can only view the information, not modify it.

Inherent in the model is the expectation that as people join and leave the collaboration it has no impact on collaborators' ability to interact with items, which have been shared with full-control granted to the collaboration. In other words, the collaboration "owns" the content, rather than any individual user. 

If someone leaves an organization, expectedly or unexpectedly, it should have no impact on the content of collaborations in which they participate. Their fellow collaborators expect to be able to carry-on with business as usual, without having to do anything extra.

In the second case, a community of dissemination, the collaboration often encompasses two tiers of users. One tier expects to operate in the partnership of equals style, while the second tier can only view information. 

This second type of collaboration often represents a later step in a workflow that starts with the first type of collaboration. A small, core team, working as equals, collaborating on information, reaches a point where they wish to disseminate a subset of their information to a community, seeking their feedback and reviews, but not permitting them to modify the information.

There are variations on these two types of collaboration, however, they are less prevalent. Support for edge cases should not come at the expense of support for the two most common cases via a simple, intuitive user experience.

Management

Users expect to be able to engage in both kinds of collaborations on their own. Those participating as equals expect to have full and equal control over creating, updating, and deleting the collaboration.

Scalability is crucial for large organizations, and no requests of or manual intervention by others, such as system administrators, should be required to manage these collaborations.

Users

Many users of the modern Esri ArcGIS Platform are new to ArcGIS. Most are not GIS Professionals in the traditional sense of desktop GIS. They have come to GIS for the light-weight web GIS tools, like Map Viewer, StoryMaps, Survey123, Collector, etc. 

These users are more often than not working collaboratively on projects, rather than on their own. 

Corollaries

The expectations of users around collaboration have been set by their experiences with other systems involved in their daily work; systems they are likely using more often than ArcGIS Online. When ArcGIS deviates significantly from those established norms, it had better have a very good reason. Otherwise, it risks setting users up for failure and unnecessarily raises the bar for them to learn the system, which can be frustrating and discourages them from using the system.

Systems like organizational file sharing solutions, productivity suites, Content Management Systems (CMS), Learning Management Systems (LMS), and other SaaS solutions are setting expectations for collaboration. These are the systems users are using day-in and day-out to engage in collaboration, such as: Google Apps, Office 365, DropBox, Google Drive, OneDrive, Box, Canvas, Blackboard, WordPress, and more....

After all, at its core, ArcGIS Online is a content management system, like Google Drive. Layered on top of that are apps, like the Map Viewer, StoryMaps, Field Maps, Survey123, Experience Builder, Insights, Hub, etc., like Google's apps on top of Drive: Docs, Sheets, Slides, Forms, Gmail, Calendar, Sites, Maps, Earth, etc.

Those other systems anchor collaboration on the items in the system, enabling users to share items with individual users and/or groups of users. They also support sharing an item in multiple ways to different combinations of individual users and/or groups.

Many of those systems also treat the organization of content separately from the sharing of content, enabling users in a partnership of equals to co-organize content within the collaboration (e.g., Google Team Drives).

Meeting the majority of modern GIS users with familiarity around collaboration means one is able to leverage intuition, reduce the need for training, and expedite work. GIS Professionals engaging in collaboration will not be slowed down either, as they are also using many of these same systems for the non-GIS portions of their work, and could also leverage their existing experience.

Use Cases

While not explicitly stated in every use case below, there is an implicit expectation that any combination of "users" (i.e., faculty, staff, students, and other collaborators) -- from one or more ArcGIS Online organizations -- can be equally involved in a collaboration with no extra effort. Users can also exit or enter a collaboration with no adverse impact on the collaboration.

• A research project utilizing ArcGIS Online, where users all have equal responsibility for the collaboration's content.
• A research project a group has been working on together in ArcGIS Online, and they now want to share it with a larger group of people they know for review.
• A service learning project that a group of users are working on, where they all have equal responsibility for the content, and now they want to share it with community stakeholders for feedback.
• A course assignment, where an instructor shares some view-only maps and layers to provide students with contextual or background information to incorporate into their assignment.
• A course assignment, where an instructor shares editable layers to provide students with a starting point for their assignment
• A group project, where students work together on a StoryMap, Web Map, Feature Layers, etc., and for which they all have equal responsibility.
• A group project students have been working on together, who now need to share it with their classmates for peer-review.
• A group project students have been working on together, who now need to turn the project (all of its components) into their instructor; the project itself, or a full clone of it, that the instructor is reviewing should no longer be editable by the students after the due date for the project.
• A finished project that a group wants to share view-only with their organization or publicly.
• A research project or course assignment where users have differing levels of responsibility across collaborations within a larger collaboration; some users have full control in some collaborations, some users are read-only participants in some collaborations, and/or some users are not involved in all collaborations.

Current State

While ArcGIS Online comes close to supporting both types of collaboration, the current experience places unnecessary roadblocks in users' paths, does not build on users' expectations and intuition, and places an unrealistic burden on system administrators. 

For instance, a Shared Update Group does most of what a partnership of equals needs, but cannot be easily instantiated by users themselves. Similarly a regular Group accomplishes much of what a community of dissemination requires, but is unexpectedly centered around the group rather than the content. 

Together, both types of groups provide some of the bits that are needed for when you have a core team of equals who later in their workflow need to disseminate information to a larger group for review; or, for when you have a large collaboration encompassing a number of overlapping, smaller collaborations. The current experience, however, is again unexpectedly centered on groups, rather than the content being the focus.