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.

[RamaSivakumar]

Peter, appreciate the thoughtful analysis. As you rightly pointed out the trend of non-gis users collaborating on the ArcGIS Online platform will only continue to grow. Robust and flexible functionality for sharing and collaboration with minimal administrative role requirement is a definite plus.

- Siva   

[JeanineFinn]

We helped substantially more users in our higher ed environment this semester with the shift to remote learning - as Peter points out, many new to ArcGIS and many interested in the more "lightweight" tools.

The ArcGIS model of named-user licenses with privileges and licensing controlled at the user level, the group level, and sometimes attached to certain pieces of content has been difficult to get new users used to. Barriers to what you're allowed to do crop up unexpected places. 

For example today a faculty member asked for help making a collaborative StoryMap available for her students to contribute to during the break. She and her students had all self-authorized (via our new SSO setup) and created their accounts and a group for their class without any admin involvement earlier in the semester.

But for this new collaboration, I had to 1) switch the faculty member into a new user type that permits ownership of a shared-update groups; 2) create a brand-new group for the class, since it's not possible to make a group shared-update once it's been live with users and content; 3) get all the students moved over to the new group; and 4) move the content they want to collaborate on to the new group.

We're meeting at 4 pm the day before break to make sure we've got all this set up properly (sound familiar?)

If I'm overlooking anything that would have made it easier, feel free to let me know.  

[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.