Samenwerkingsmodellen voor ArcGIS Online

PeterKnoop

De bedoeling van dit bericht is om discussie te stimuleren over de verwachtingen van gebruikers met betrekking tot samenwerking, en hoe ArcGIS Online beter aan deze behoeften kan voldoen. Het gaat niet om het delen of zoeken naar oplossingen voor de beperkingen en omstandigheden die momenteel door het systeem worden opgelegd. <\/SPAN><\/P>Typen<\/SPAN><\/H3>Over het algemeen willen gebruikers twee belangrijke soorten samenwerking bereiken in ArcGIS Online: <\/SPAN><\/P>Partnerschap van gelijken<\/SPAN><\/LI>Gemeenschap van verspreiding<\/SPAN><\/LI><\/OL>In het eerste geval stemmen de leden van de samenwerking ermee in elkaar als gelijken te behandelen en delen zij de verantwoordelijkheid voor de samenwerking. Wanneer ze informatie delen binnen de samenwerking, kunnen ze ervoor kiezen deze te delen met volledige controle of alleen-lezen toegang verleend aan hun mede-samenwerkers.<\/SPAN><\/P>Bij het delen met volledige controle verwachten ze dat samenwerkers alles met de informatie kunnen doen, ongeacht wie deze oorspronkelijk heeft gemaakt of geschreven. Bij het delen met alleen-lezen is de verwachting dat mede-samenwerkers de informatie alleen kunnen bekijken, niet wijzigen.<\/SPAN><\/P>Inherent aan het model is de verwachting dat wanneer mensen toetreden tot of vertrekken uit de samenwerking, dit geen invloed heeft op het vermogen van samenwerkers om te interageren met items die met volledige controle aan de samenwerking zijn gedeeld. Met andere woorden, de samenwerking "eigent" zich de inhoud toe, in plaats van een individuele gebruiker. <\/SPAN><\/P>Als iemand een organisatie verlaat, verwacht of onverwacht, mag dit geen invloed hebben op de inhoud van samenwerkingen waarin zij deelnemen. Hun mede-samenwerkers verwachten hun werk als gewoonlijk voort te zetten zonder extra handelingen.<\/SPAN><\/P>In het tweede geval, een gemeenschap van verspreiding, omvat de samenwerking vaak twee niveaus van gebruikers. Eén niveau verwacht te opereren in de stijl van partnerschap van gelijken, terwijl het tweede niveau alleen informatie kan bekijken. <\/SPAN><\/P>Dit tweede type samenwerking vertegenwoordigt vaak een latere stap in een workflow die begint met het eerste type samenwerking. Een klein kernteam, werkend als gelijken en samenwerkend aan informatie, bereikt een punt waarop ze een subset van hun informatie willen verspreiden naar een gemeenschap om feedback en beoordelingen te verkrijgen, maar hen niet toestaan de informatie te wijzigen.<\/SPAN><\/P>Er zijn variaties op deze twee soorten samenwerking, maar deze zijn minder voorkomend. Ondersteuning voor randgevallen mag niet ten koste gaan van ondersteuning voor de twee meest voorkomende gevallen via een eenvoudige, intuïtieve gebruikerservaring.<\/SPAN><\/P>Beheer<\/SPAN><\/H3>Gebruikers verwachten zelfstandig beide soorten samenwerkingen te kunnen aangaan. Degenen die deelnemen als gelijken verwachten volledige en gelijke controle over het creëren, bijwerken en verwijderen van de samenwerking.<\/SPAN><\/P>Schaalbaarheid is cruciaal voor grote organisaties, en er mogen geen verzoeken of handmatige interventies door anderen, zoals systeembeheerders, nodig zijn om deze samenwerkingen te beheren.<\/SPAN><\/P>Gebruikers<\/SPAN><\/H3>Veel gebruikers van het moderne Esri ArcGIS Platform zijn nieuw in ArcGIS. De meesten zijn geen GIS Professionals in traditionele zin van desktop GIS. Ze zijn naar GIS gekomen vanwege de lichtgewicht web GIS-tools zoals Map Viewer, StoryMaps, Survey123, Collector, enz. <\/SPAN><\/P>Deze gebruikers werken vaker samen aan projecten dan individueel. <\/SPAN><\/P>Gevolgen<\/SPAN><\/H3>De verwachtingen van gebruikers rond samenwerking zijn gevormd door hun ervaringen met andere systemen die betrokken zijn bij hun dagelijkse werk; systemen die ze waarschijnlijk vaker gebruiken dan ArcGIS Online. Wanneer ArcGIS significant afwijkt van die gevestigde normen, moet daar een zeer goede reden voor zijn. Anders loopt het risico gebruikers op achterstand te zetten en onnodig de drempel om het systeem te leren te verhogen, wat frustrerend kan zijn en ontmoedigt om het systeem te gebruiken.<\/SPAN><\/P>Systemen zoals organisatorische bestandsdelingsoplossingen, productiviteitssuites, Content Management Systemen (CMS), Learning Management Systemen (LMS) en andere SaaS-oplossingen bepalen verwachtingen voor samenwerking. Dit zijn systemen die gebruikers dagelijks gebruiken om samen te werken, zoals: Google Apps, Office 365, DropBox, Google Drive, OneDrive, Box, Canvas, Blackboard, WordPress en meer....<\/SPAN><\/P>Immers is ArcGIS Online in essentie een content management systeem zoals Google Drive. Daarbovenop liggen apps zoals Map Viewer, StoryMaps, Field Maps, Survey123, Experience Builder, Insights, Hub enz., vergelijkbaar met Google's apps bovenop Drive: Docs, Sheets, Slides, Forms, Gmail, Calendar, Sites, Maps, Earth enz.<\/SPAN><\/P>Die andere systemen baseren samenwerking op items in het systeem en stellen gebruikers in staat items te delen met individuele gebruikers en/of groepen gebruikers. Ze ondersteunen ook het delen van een item op meerdere manieren met verschillende combinaties van individuele gebruikers en/of groepen.<\/SPAN><\/P>Veel van die systemen behandelen ook de organisatie van content apart van het delen ervan en stellen gebruikers in een partnerschap van gelijken in staat om gezamenlijk content binnen de samenwerking te organiseren (bijv. Google Team Drives).<\/SPAN><\/P>Aansluiten bij de meerderheid van moderne GIS-gebruikers met vertrouwdheid rond samenwerking betekent dat men intuïtie kan benutten, trainingsbehoefte kan verminderen en werk kan versnellen. GIS Professionals die samenwerken worden ook niet vertraagd omdat zij veel van dezelfde systemen gebruiken voor niet-GIS gedeelten van hun werk en zo hun bestaande ervaring kunnen benutten.<\/SPAN><\/P>Gebruikssituaties<\/SPAN><\/H3>Hoewel niet expliciet vermeld in elke onderstaande gebruikssituatie is er een impliciete verwachting dat elke combinatie van "gebruikers" (d.w.z. docenten, personeel, studenten en andere samenwerkers) -- uit één of meer ArcGIS Online organisaties -- gelijkwaardig betrokken kan zijn bij een samenwerking zonder extra inspanning. Gebruikers kunnen ook zonder nadelige gevolgen een samenwerking verlaten of betreden.<\/SPAN><\/P>Een onderzoeksproject dat ArcGIS Online gebruikt waarbij alle gebruikers gelijke verantwoordelijkheid dragen voor de inhoud van de samenwerking.<\/SPAN><\/LI>Een onderzoeksproject waaraan een groep samen heeft gewerkt in ArcGIS Online en dat ze nu willen delen met een grotere groep bekenden ter beoordeling.<\/SPAN><\/LI>Een service learning project waaraan een groep gebruikers werkt waarbij zij allemaal gelijke verantwoordelijkheid hebben voor de inhoud en dat ze nu willen delen met belanghebbenden uit de gemeenschap voor feedback.<\/SPAN><\/LI>Een cursusopdracht waarbij een docent enkele alleen-lezen kaarten en lagen deelt om studenten contextuele of achtergrondinformatie te bieden die ze kunnen verwerken in hun opdracht.<\/SPAN><\/LI >Een cursusopdracht waarbij een docent bewerkbare lagen deelt om studenten een startpunt voor hun opdracht te geven< \/ SPAN >< \/ LI >< SPAN >Een groepsproject waarbij studenten samenwerken aan een StoryMap , Web Map , Feature Layers , enz., waarvoor zij allemaal gelijke verantwoordelijkheid dragen . < \/ SPAN >< \/ LI >< SPAN >Een groepsproject waaraan studenten samen hebben gewerkt , dat ze nu moeten delen met hun klasgenoten voor peer-review . < \/ SPAN >< \/ LI >< SPAN >Een groepsproject waaraan studenten samen hebben gewerkt , dat ze nu moeten overhandigen aan hun docent ; het project zelf , of een volledige kloon ervan , dat door de docent wordt beoordeeld , mag na de deadline niet langer bewerkbaar zijn door studenten . < \/ SPAN >< \/ LI >< SPAN >Een afgerond project dat een groep alleen-lezen wil delen met hun organisatie of publiek . < \/ SPAN >< \/ LI >< SPAN >Een onderzoeksproject of cursusopdracht waarbij gebruikers verschillende verantwoordelijkheidsniveaus hebben binnen samenwerkingen binnen een grotere samenwerking ; sommige gebruikers hebben volledige controle in sommige samenwerkingen , sommige gebruikers zijn alleen-lezen deelnemers in sommige samenwerkingen , en/of sommige gebruikers zijn niet betrokken bij alle samenwerkingen . < \/ SPAN >< \/ LI >< \/ UL >< H3 id = " toc-hId-605675904 " >< SPAN >Huidige situatie < \/ SPAN >< \/ H3 >< P >< SPAN >Hoewel ArcGIS Online dicht bij ondersteuning komt voor beide soorten samenwerking , plaatst de huidige ervaring onnodige obstakels op het pad van gebruikers , bouwt niet voort op verwachtingen en intuïtie van gebruikers , en legt onrealistische lasten op systeembeheerders . & nbsp ; < \/ SPAN >< \/ P >< P >< SPAN >Bijvoorbeeld doet een Shared Update Group bijna alles wat nodig is voor een partnerschap van gelijken , maar kan niet gemakkelijk door gebruikers zelf worden opgezet . Evenzo bereikt een gewone Group veel van wat nodig is voor een gemeenschap van verspreiding , maar is onverwacht gecentreerd rond de groep in plaats van rond de inhoud . & nbsp ; < \/ SPAN >< \/ P >< P >< SPAN >Samen bieden beide typen groepen enkele elementen die nodig zijn wanneer je een kernteam hebt dat later in hun workflow informatie moet verspreiden naar een grotere groep ter beoordeling ; of wanneer je een grote samenwerking hebt die meerdere overlappende kleinere samenwerkingen omvat . De huidige ervaring is echter opnieuw onverwacht gericht op groepen , in plaats van dat content centraal staat . < \/ SPAN >< \/ P >

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.