Modely spolupráce pro ArcGIS Online

PeterKnoop

Cílem tohoto příspěvku je podnítit diskusi ohledně očekávání uživatelů týkajících se spolupráce a jak by ArcGIS Online mohl lépe sloužit těmto potřebám. Nejde o sdílení nebo hledání obcházek omezení a okolností, které systém v současnosti ukládá. <\/SPAN><\/P>Typy<\/SPAN><\/H3>Obecně uživatelé chtějí dosáhnout dvou hlavních druhů spolupráce v ArcGIS Online: <\/SPAN><\/P>Partnerství rovnocenných<\/SPAN><\/LI>Komunita šíření<\/SPAN><\/LI><\/OL>V prvním případě se členové spolupráce dohodnou, že se budou navzájem považovat za rovnocenné a sdílet odpovědnost za spolupráci. Když sdílejí informace ve spolupráci, mohou si vybrat, zda je sdílí s plným řízením nebo pouze s přístupem pro zobrazení uděleným svým spolupracovníkům.<\/SPAN><\/P>Při sdílení s plným řízením očekávají, že spolupracovníci budou moci s informacemi dělat cokoli, bez ohledu na to, kdo je původně vytvořil nebo autorem. Při sdílení pouze pro zobrazení je očekávání, že ostatní spolupracovníci mohou informace pouze zobrazit, nikoli upravovat.<\/SPAN><\/P>V modelu je inherentní očekávání, že když lidé vstupují do spolupráce nebo ji opouštějí, nemá to žádný dopad na schopnost spolupracovníků interagovat s položkami, které byly sdíleny s plným řízením uděleným spolupráci. Jinými slovy, obsah „vlastní“ spolupráce, nikoli jednotlivý uživatel. <\/SPAN><\/P>Když někdo opustí organizaci, očekávaně či neočekávaně, nemělo by to mít žádný dopad na obsah spoluprací, kterých se účastní. Jejich spolupracovníci očekávají, že budou moci pokračovat v běžné práci bez nutnosti činit další kroky.<\/SPAN><\/P>Ve druhém případě, komunitě šíření, často spolupráce zahrnuje dvě úrovně uživatelů. Jedna úroveň očekává fungování ve stylu partnerství rovnocenných, zatímco druhá úroveň může pouze zobrazovat informace. <\/SPAN><\/P>Tento druhý typ spolupráce často představuje pozdější krok v pracovním postupu začínajícím prvním typem spolupráce. Malý jádrový tým pracující jako rovnocenní na informacích dosáhne bodu, kdy chce podmnožinu svých informací šířit komunitě za účelem získání zpětné vazby a recenzí, ale neumožňuje jim informace upravovat.<\/SPAN><\/P>Existují variace těchto dvou typů spolupráce, avšak jsou méně rozšířené. Podpora okrajových případů by neměla být na úkor podpory dvou nejběžnějších případů prostřednictvím jednoduchého a intuitivního uživatelského zážitku.<\/SPAN><\/P>Správa<\/SPAN><\/H3>Uživatelé očekávají možnost zapojit se do obou druhů spolupráce samostatně. Ti, kteří se účastní jako rovnocenní partneři, očekávají plnou a rovnou kontrolu nad vytvářením, aktualizací a mazáním spolupráce.<\/SPAN><\/P>Škálovatelnost je klíčová pro velké organizace a neměly by být vyžadovány žádné požadavky ani ruční zásahy jiných osob, jako jsou systémoví administrátoři, k řízení těchto spoluprací.<\/SPAN><\/P>Uživatelé<\/SPAN><\/H3>Mnoho uživatelů moderní platformy Esri ArcGIS je nových v ArcGIS. Většina nejsou GIS profesionálové v tradičním smyslu desktopového GIS. Přišli k GIS kvůli lehkým webovým nástrojům GIS, jako jsou Map Viewer, StoryMaps, Survey123, Collector atd. <\/SPAN><\/P>Tito uživatelé často pracují na projektech společně spíše než samostatně. <\/SPAN><\/P>Důsledky<\/SPAN><\/H3>Očekávání uživatelů ohledně spolupráce byla nastavena jejich zkušenostmi s jinými systémy používanými v jejich každodenní práci; systémy, které pravděpodobně používají častěji než ArcGIS Online. Když ArcGIS výrazně odchyluje od těchto zavedených norem, musí mít velmi dobrý důvod. Jinak riskuje nastavení uživatelů na neúspěch a zbytečně zvyšuje nároky na učení systému, což může být frustrující a odrazuje je od používání systému.<\/SPAN><\/P>Systémy jako organizační řešení pro sdílení souborů, produktivní balíčky, Content Management Systems (CMS), Learning Management Systems (LMS) a další SaaS řešení nastavují očekávání pro spolupráci. Jsou to systémy, které uživatelé den co den používají ke spolupráci, například: Google Apps, Office 365, DropBox, Google Drive, OneDrive, Box, Canvas, Blackboard, WordPress a další....<\/SPAN><\/P>Koneckonců ArcGIS Online je v jádru systém pro správu obsahu podobný Google Drive. Na tom jsou vrstveny aplikace jako Map Viewer, StoryMaps, Field Maps, Survey123, Experience Builder, Insights, Hub atd., podobně jako Google aplikace nad Drive: Docs, Sheets, Slides, Forms, Gmail, Calendar, Sites, Maps, Earth atd.<\/SPAN><\/P>Tyto ostatní systémy zakládají spolupráci na položkách v systému a umožňují uživatelům sdílet položky s jednotlivými uživateli a/nebo skupinami uživatelů. Také podporují sdílení položky různými způsoby s různými kombinacemi jednotlivých uživatelů a/nebo skupin.<\/SPAN><\/P>Mnoho z těchto systémů také odděluje organizaci obsahu od jeho sdílení a umožňuje uživatelům v partnerství rovnocenných spoluspravovat obsah uvnitř spolupráce (například Google Team Drives).<\/SPAN><\/P>Setkání většiny moderních GIS uživatelů s povědomím o spolupráci znamená využití intuice, snížení potřeby školení a urychlení práce. GIS profesionálové zapojení do spolupráce nebudou zpomaleni ani oni; také používají mnoho z těchto stejných systémů pro ne-GIS části své práce a mohou tak využít své stávající zkušenosti.<\/SPAN><\/P>Případy použití<\/SPAN><\/H3>Ačkoli není výslovně uvedeno v každém níže uvedeném případě použití, existuje implicitní očekávání že jakákoli kombinace „uživatelů“ (tj. fakulty, zaměstnanců, studentů a dalších spolupracovníků) – z jedné či více organizací ArcGIS Online – může být stejně zapojena do spolupráce bez dodatečné námahy. Uživatelé také mohou vstoupit nebo opustit spolupráci bez negativního dopadu na ni.<\/SPAN><\/P>Výzkumný projekt využívající ArcGIS Online kde všichni uživatelé mají stejnou odpovědnost za obsah spolupráce.<\/SPAN>Výzkumný projekt na kterém skupina společně pracovala v ArcGIS Online a nyní ho chce sdílet s větší skupinou známých k recenzi.<\/SPAN>Projekt služebního učení na kterém skupina uživatelů pracuje kde všichni mají stejnou odpovědnost za obsah a nyní ho chtějí sdílet s komunitními zainteresovanými stranami k získání zpětné vazby.<\/SPAN>Zadání kurzu kde instruktor sdílí některé mapy a vrstvy pouze pro zobrazení aby studentům poskytl kontextové nebo základní informace k začlenění do jejich zadání.<\/SPAN>Zadání kurzu kde instruktor sdílí editovatelné vrstvy aby studentům poskytl výchozí bod pro jejich zadání<\/SPAN>Skupinový projekt kde studenti společně pracují na StoryMapu Web Mapách Feature Layers atd., za který všichni nesou stejnou odpovědnost.<\/SPAN>Skupinový projekt na kterém studenti společně pracovali a nyní ho musí sdílet se svými spolužáky k vzájemnému hodnocení.<\/SPAN>Skupinový projekt na kterém studenti společně pracovali který nyní musí předat instruktorovi; projekt samotný nebo jeho plná kopie kterou instruktor hodnotí by již po termínu odevzdání neměla být studenty editovatelná.<\/Span>


Dokončený projekt který skupina chce sdílet pouze pro zobrazení se svou organizací nebo veřejně.




Výzkumný projekt nebo zadání kurzu kde uživatelé mají různé úrovně odpovědnosti napříč kolaboracemi uvnitř větší kolaborace; někteří uživatelé mají plnou kontrolu v některých kolaboracích někteří jsou pouze čtecími účastníky v některých kolaboracích a/nebo někteří nejsou zapojeni ve všech kolaboracích.





Současný stav




I když ArcGIS Online téměř podporuje oba typy kolaborace současná zkušenost klade zbytečné překážky na cestu uživatelům nevyužívá jejich očekávání ani intuici a klade nereálnou zátěž na systémové administrátory.

Například Shared Update Group dělá většinu toho co partnerství rovnocenných potřebuje ale nemůže být snadno vytvořena samotnými uživateli. Podobně běžná Group splňuje mnoho požadavků komunity šíření ale neočekávaně je zaměřena kolem skupiny spíš než kolem obsahu.

Oba typy skupin dohromady poskytují některé části potřebné když máte jádrový tým rovnocenných kteří později ve svém pracovním postupu potřebují šířit informace větší skupině k recenzi; nebo když máte velkou kolaboraci zahrnující řadu překrývajících se menších kolaborací. Současná zkušenost je však opět neočekávaně zaměřena na skupiny místo aby byl středem pozornosti obsah.

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.