Latest Contributions by BillSimper

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening! ... View more

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening! ... View more

In my field (conservation biology), there will always be a need for users to have access to offline basemaps. This is an area which is often fraught with problems for lots of users for various reasons. On Collector/Explorer-- the mechanism is pretty good. There's room for improvement but generally a persistent user can get what they need and if a download fails at least you know it failed (though these error messages could be much more informative!). There's even a mechanism for sharing basemaps across different maps/projects for a given user. However, they cannot be shared with other apps (as far as I know). On Survey123-- offline basemaps are a pain for form developers to create and the download process for users isn't great. Often, with large basemaps they will partially download and quit, but not show an error message-- instead they just won't work and the user won't know why (without checking the file size on device vs ArcGIS Online). Also, the user must manually go in and specify which basemap they want showing with EVERY individual survey-form-record-- it doesn't persist (unless it's specified by the form designer, which has other problematic effects if the specified basemap wasn't downloaded). On QuickCapture-- ability to use web maps and standard basemaps is awesome. However MUST be used in Online mode. Kudos for keeping it simple (in the spirit of QuickCapture) but not great for obligatory offline-mode users. So my proposal is to create a mechanism by which offline basemaps that are downloaded to device are available to ALL ArcGIS mobile apps (above) on that device. Ideally the user would be able to specify which basemap (or series of basemaps in order of user-specified priority or spatial extent / zoom level in relation to current location) they want to use in the Settings for a given app (and this would persist across surveys/projects/records until changed in App Settings by user). Additionally, I'd suggest creating a dedicated stand-alone mobile app for downloading these shared-offline basemaps. This would standardize the process across all apps, while also saving your app-development teams from having to re-invent the download interface for each particular app. If there was a dedicated development team for this downloader app, then the focus could be making it both flexible and bullet-proof functionally as well as easy and intuitive to use (and fully documented) and the other mobile apps would benefit from this. It also means that I, the form designer and technical intermediary in our organization, only have to teach one methodology for obtaining these necessary basemaps instead of keeping track of different capabilities across each app (which I can do with effort, but can be very confusing at the end user level). Thanks for listening! ... View more

Since 2018 I've been using Survey123's custom URL scheme to launch Survey123 forms from other Survey123 forms to create a hierarchy of parent-child forms/data layers. This allows me to make a complicated system of forms modular and avoids some problems that arise using Repeats (the major one back in the day was that you couldn't do nested repeats admittedly having since been changed). When doing this I had been able to successfully pass data from multiple fields in parent forms to child forms using the well known format (e.g. arcgis-survey123://?itemID=36ff9e8c13e042a58cfce4ad87f55d19&field:surname=Klauser) as described here. Specifically I've been using the calculation parameter of XLSFORM to assemble the URL and create the link as a text question type to dynamically pass field values (text and numeric data types). Here's a typical example using the concat function: concat('<a href="arcgis-survey123://?itemID=XXXXXXXXXXXXXXXXXXXXXXXXX&field:parent_uuid=',${survey_uuid}, '&field:individual_id=', ${individual_id}, '&field:alive_dead=', ${alive_dead}, '&field:sex=',${sex}, '">Click here to open a CHILD form.</a>') However, I'm now seeing this failing in my forms. The correct Survey123 form will launch when the link is clicked, but no survey data is being passed. After failing to get this to work for one form a user reported a problem with, I decided to check out other forms that have been working-- they don't work now either. Then I started trying older versions of Survey123 field app (I keep old versions installed on my desktop for this purpose). Long story short, the URL scheme's worked as expected up to version 3.2. Version 3.5 and 3.7 are failing. Most likely this wasn't reported earlier since most of the forms I use this functionality with get used in the spring and version 3.5 came out last summer. However I really need this working for upcoming spring surveys. I should mention that I use the field app almost exclusively-- so this all pertains to field app, not sure if web app showing the same problem. Has there been some kind of change to the way Survey123's URL scheme works? Thanks! ... View more

Here's a typical situation. I have a hosted feature layer set to allow editing (add, update and delete). I add it to a web map with full editing control and save the web map, going to the trouble of naming the map, adding tags, adjusting sharing, setting up cartography, table of contents, labelling. The web map is intended for use by end users to edit their own data, including deleting records. I try it out myself and it works.  I add some records, typically through Survey123, to make some final adjustments to a form in development. These adjustments within Survey123 don't involve any schema changes or deletion/recreation of the original HFL, merely form-internal 'cosmetic' or form-logic changes. By the time I'm done, I want to delete the test records and now when I click on the records, the option to 'edit' is no longer part of the pop-up. Typically this is in a map/browser window that's been open the entire time I've been testing my form, i.e. 30 mins to couple of hours. Reloading the page, re-opening from Contents, logging out and back in, and restarting in a new browser window don't fix the problem.  Why does this ability 'go away'? As I mentioned, the layer is configured to allow editing by the users, and in addition I'm the owner of the all of the components of the web map, having assembled the entire set-up. Editing seems to still function-- I can toggle the Edit tab/button and thereby add points and it looks like I can still edit field values as well. But I and my users need the ability to delete individual records. As far as I'm aware, this is only possible via clicking on the feature in a web map, not in the attribute table or in the Data tab of the HFL. I know that it's possible to do this by going the the HFL item description page and opening it into another web map with full editing control. However, I need to be able to set up reliable QA/QC maps for our end users and not have them constantly creating temporary utility maps (which is well beyond the level of experience a typical end user has or should be expected to have). I've encountered this problem sporadically and tended to attribute it to some configuration mistake I've made, but today it's happened several times in a row over the course of a day, and I'm confident I'm not doing anything 'wrong' (that I'm aware of) and I use AGOL on a daily basis, so I'm not a novice user. It's an incredible waste of time to have to start from scratch to set up a map, not to mention the massive confusion for the end users. Can someone shed some light on this? On a related note, what exactly is 'full editing control' and why isn't this the default condition for any HFL that has been configured to allow editing? If it confers important additional capabilities, how can this be specified when adding a layer from the web to an existing web map-- as far as I know it's only possible to enable this for a single layer when adding to a brand new web map from the HFL's item description page. And finally, am I missing something or is there a better way to delete features than highlighting them in a web map and using the delete button in a pop-up? Even when this is working it's EXTREMELY convoluted, as you have to find the record in the attribute table, then zoom your map to it, click on the feature, toggle through any coincident features (very confusing to end users and arises fairly often), then when you've found it, click on 'edit this feature' (IF this is working properly), then you may have to select the feature again, then you can click the button to delete. Ideally, a user should be able to delete a selected record in the attribute table (just like they can in ArcMap) AND at in the data view for that HFL (although that really requires more experience than our end users are ever likely to have). Thanks in advance for any help on this topic! ... View more