ArcGIS Onlineのコラボレーションモデル

PeterKnoop

この投稿の目的は、ユーザーのコラボレーションに対する期待について議論を促進し、ArcGIS Onlineがこれらのニーズにどのようにより良く対応できるかを考えることです。これは、システムによって現在課されている制限や状況の回避策を共有したり探したりすることではありません。 <\/SPAN><\/P>タイプ<\/SPAN><\/H3>一般的にユーザーはArcGIS Onlineで2つの主要な種類のコラボレーションを達成しようとしています: <\/SPAN><\/P>対等なパートナーシップ<\/SPAN><\/LI>情報発信コミュニティ<\/SPAN><\/LI><\/OL>最初の場合、コラボレーションのメンバーは互いを対等とみなし、コラボレーションに対する責任を共有することに同意しています。彼らがコラボレーション内で情報を共有するとき、共同作業者にフルコントロールまたは閲覧のみアクセス権を付与して共有することができます。<\/SPAN><\/P>フルコントロールで共有する場合、共同作業者は元々誰が作成または著作したかに関係なく、その情報で何でもできることを期待しています。閲覧のみで共有する場合、共同作業者は情報を見ることだけができ、変更はできないという期待があります。<\/SPAN><\/P>このモデルには、人がコラボレーションに参加したり離れたりしても、フルコントロールが付与されたアイテムとのやり取り能力に影響がないという期待が内在しています。言い換えれば、コンテンツは個々のユーザーではなく、コラボレーション自体が「所有」しているということです。 <\/SPAN><\/P>誰かが組織を離れた場合（予期せずとも予期していても）、彼らが参加しているコラボレーションのコンテンツには影響がないはずです。共同作業者は通常通り業務を続けることができ、追加の手間をかける必要はありません。<\/SPAN><\/P>2番目の場合、情報発信コミュニティでは、コラボレーションはしばしば2層のユーザーで構成されます。一方の層は対等なパートナーシップスタイルで操作し、もう一方の層は情報を見るだけです。 <\/SPAN><\/P>この2番目のタイプのコラボレーションは、多くの場合最初のタイプのコラボレーションから始まるワークフローの後段階を表します。少人数のコアチームが対等に協力して情報を共有し、その一部をコミュニティに配布してフィードバックやレビューを求めますが、情報の変更は許可しません。<\/SPAN><\/P>これら2つのタイプにはバリエーションがありますが、それらはあまり一般的ではありません。エッジケースへの対応は、シンプルで直感的なユーザー体験による2つの最も一般的なケースへのサポートを犠牲にすべきではありません。<\/SPAN><\/P>管理<\/SPAN><\/H3>ユーザーは両方の種類のコラボレーションに自分自身で参加できることを期待しています。対等な立場で参加する人々は、コラボレーションの作成、更新、および削除に完全かつ平等な権限を持つことを期待しています。<\/SPAN><\/P>大規模組織にとってスケーラビリティは重要であり、システム管理者など他者からの要求や手動介入なしでこれらのコラボレーションを管理できるべきです。<\/SPAN><\/P>ユーザー<\/SPAN><\/H3>現代Esri ArcGIS Platformの多くのユーザーはArcGIS初心者です。ほとんどは従来型デスクトップGISのGIS専門家ではありません。彼らはMap Viewer、StoryMaps、Survey123、Collectorなど軽量なWeb GISツール目的でGISに来ています。 <\/SPAN><\/P>これらのユーザーは多くの場合、自分一人ではなくプロジェクトで協力して作業しています。 <\/SPAN><\/P>相関関係<\/SPAN><\/H3>ユーザーのコラボレーションに関する期待は、日常業務で使用している他システムで培われた経験によって形成されています。それらシステムはArcGIS Onlineより頻繁に使われている可能性があります。ArcGISがそれら確立された基準から大きく逸脱するとき、それには非常に良い理由が必要です。そうでなければユーザーを失敗させるリスクがあり、不必要に学習ハードルを上げてしまい、それがフラストレーションとなり利用意欲を削ぐ恐れがあります。<\/SPAN><\/P>組織ファイル共有ソリューション、生産性スイート、コンテンツ管理システム（CMS）、学習管理システム（LMS）、その他SaaSソリューションなどがコラボレーションへの期待値を設定しています。これらはGoogle Apps, Office 365, DropBox, Google Drive, OneDrive, Box, Canvas, Blackboard, WordPressなど日常的に使われているシステムです....<\/SPAN><\/P>結局のところArcGIS OnlineはGoogle Driveのようなコンテンツ管理システムです。その上にMap Viewer, StoryMaps, Field Maps, Survey123, Experience Builder, Insights, Hubなどアプリケーションが重ねられており、それはGoogle Drive上のDocs, Sheets, Slides, Forms, Gmail, Calendar, Sites, Maps, EarthなどGoogleアプリと似ています。<\/SPAN><\/P>これら他システムではアイテム単位でコラボレーションが基盤となっており、個別ユーザーやグループとアイテム共有できます。また複数方法で異なる組み合わせへアイテム共有もサポートします。<\/SPAN><\/P>多くの場合これらシステムではコンテンツ整理と共有を別扱いとしており、対等パートナー間でコンテンツ整理も共同管理可能です（例：Google Team Drives）。<\/SPAN><\/P>現代GISユーザー多数と親和性あるコラボレーション体験とは直感活用可能でトレーニング不要化し作業迅速化につながります。またGIS専門家も非GIS部分業務で同様システム利用経験あるため遅延なく活用可能です。<\/SPAN><\/P>ユースケース<\/SPAN><\/H3>以下すべて明示されてはいませんが、「ユーザー」（教職員、学生その他共同作業者）が1つ以上のArcGIS Online組織から混在していても追加努力なしに平等参加できる暗黙的期待があります。またユーザー出入りによる悪影響もありません。<\/SPAN><\/P>ArcGIS Onlineを利用した研究プロジェクトで全員がコンテンツ責任を平等に負う場合。<\/SPAN>グループで進めていた研究プロジェクトをより大きな知人グループへレビュー目的で共有したい場合。<\/SPAN>サービスラーニングプロジェクトで全員がコンテンツ責任平等だが地域関係者へフィードバック求めて共有したい場合。<\/SPAN>講義課題として教員が学生へ文脈や背景情報提供用に閲覧のみマップやレイヤー共有する場合。<\/SPAN>講義課題として教員が学生へ編集可能レイヤー提供し課題開始点とする場合<\/SPAN>学生グループプロジェクトとしてStoryMapやWeb Map、Feature Layersなど共同制作し全員責任平等の場合。<\/Span>


学生グループプロジェクト作品をクラスメイトへピアレビュー目的で共有したい場合。




学生グループプロジェクト作品（全構成要素）を教員へ提出し評価受けたい場合；提出後学生による編集不可となるべき。




完成プロジェクトを組織内または公開向けに閲覧のみ共有したい場合。




研究プロジェクトや講義課題で複数コラボレーション内役割異なる場合；一部ユーザーはフルコントロール、一部閲覧のみ、一部未参加など。



現状


ArcGIS Online は両タイプのコラボレーション対応に近いものの現状体験には不必要な障害があり、ユーザー期待や直感に基づかずシステム管理者への過度負担もあります。

例えばShared Update Group は対等パートナーシップ要件多く満たしますがユーザー自身による簡単生成不可です。同様に通常Group は情報発信コミュニティ要件多く満たしますが意外にもグループ中心設計でコンテンツ中心ではありません。

両種グループ合わせて対等チームから後段階として大規模レビュー用配布や重複小規模複数コラボ含む大規模協働時必要要素一部提供します。しかし現状体験も再びグループ中心設計でコンテンツ中心ではありません。

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.