Latest Contributions by PeterKnoop

The applications usage report for ArcGIS Online produced by the Python API (AGOLUsageReports) uses appIds to identify the applications. Is there documentation that provides the official mapping of appId to Esri product?  For example, "arcgisprodesktop", "arcgispro", "arcgisdesktop", and "arcgisdesktop102" all show up as appIds in our application usage report over the last few months. Is "arcgisprodesktop" capturing both the use of Pro and Desktop? Or, is it only tied to use of Pro? Which version(s) of Pro (and Desktop) does it represent? Is "arcgispro" only earlier version of Pro, and, if so, which versions? I'm guessing "arcgisdesktop102" means someone using ArcGIS Desktop 10.2 still? ... View more

You should be able to add a side legend to a Serial Chart that has only one series, so that it behaves the same as a Serial Chart with multiple series. Currently the legend option only appears when you have more than one series in the chart. If you have a collection of Serial Chart elements laid out vertically one above the other, and some are single series and some have multiple series, and you have side legends enabled for the multiple series charts, then their X-axis will be of different lengths. That difference in X-axes' lengths makes it difficult to visually compare the charts to see what lines up with what vertically. By enabling the side legend for a Serial Chart that only has one series, then it too will have an X-axis that is shortened to make room for the side legend, then everything will align correctly vertically across all the Serial Chart elements. For example, in the Dashboard below all the data is using the same time range for its X-axis, but various parameters have been group together in different Serial Charts. Because the top Serial Chart only has one series in it, you cannot turn on the side legend, so its X-axis values do not align with charts below it. ... View more

The new Map Viewer, or Map Viewer Beta, offers many new and exciting features, as well as performance improvements. Its user experience, however, adds significant challenges over the original Map Viewer when using it on a device with limited screen real estate. Is there a way for a user to adjust their new Map Viewer experience to get more of their map view back, when all they have is a low-resolution display? In the Education world, where students' personal devices and institutional equipment is often far from state-of-the-art, this screen real-estate issue presents a significant hurdle. It is especially problematic for the many users taking their first steps in learning GIS. (And, during the pandemic, students are almost exclusively limited to working on personal devices, without physical access to large displays in on-premise computing labs.) The look-and-feel of the Map Viewer Beta is great when you are looking at a map: A very cool map!   But what if you want to interact with that map?  What if you are the person authoring the map? If you are toggling layers, adjusting symbology, experimenting with clustering settings, filtering data, examining the attribute table, saving the map, sharing it, and so on… and, if you are on a 1024x768 display, then the user experience leaves a lot to be desired.   Where did the map go?   The map is reduced to a small sliver -- only 12% of the display! -- making it hard to see the impact of any changes you are making. Yes, you can expand and collapse some of the panes to see more of the map as you tweak things, however, that functionality is often hidden below the fold (see the left and right panes in the above image), and the user has to perform extra scrolling to access it.  Also, remember that students' computers are often a couple years old on average, and were not that powerful in the first place. Hence, expanding and collapsing panes to expose enough of the map to check out changes, and then get back to the settings does not happen fast, and is frustrating to have to do repeatedly. Even with the resolution increased to 1440x900, the map still only occupies 27% of the display. And, yes, you can zoom the map, however, you will lose detail you might need as you are updating the map's settings.   An estimated three-quarters of the web traffic to campus from student desktop (not mobile) web browsers during our hybrid Fall 2020 semester has been at 1440x900 or less! Not to mention students don't always expand their browser to full-screen when they are working in multiple applications.   There is a bit more map here, but still less than one-third of the screen.   The user experience in the old Map Viewer maintained the primacy of the map as you configured it. No, it wasn't my favourite user experience. The old Map Viewer has its own set of eccentricities. In many ways the Map Viewer Beta represents an important and helpful evolution, however, its multitude of separate panes seems like a step backwards in some ways, particularly for those with limited display resolution.   Which brings me back to the original question, is there a way for a user to adjust their Map Viewer Beta experience to get more of their map view back, when all they have is a low-resolution display?   The map in the Map Viewer Beta looks great and is easy to work with... when you have a 3200x1800 display on a nice big 5K monitor. The map occupies 80% of the screen with all the panes expanded and nothing is hidden below a fold.   ... View more

I entered text in the Article Teaser field for the following blog post, however, I do not see it displayed as expected when I view the Latest Activity for that community. Instead is displaying the first few lines of the post itself. https://community.esri.com/t5/arcgis-online-blog/collaboration-models-for-arcgis-online/ba-p/1003408#M744 How does one get the teaser text to work? Thanks! ... View more

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:  Partnership of equals 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. ... View more