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.
Generally users are looking to accomplish two major kinds of collaboration in ArcGIS Online:
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.
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.
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.
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.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.