Latest Contributions by BillSimper

Hi, writing in to report a pernicious problem that is cropping up in certain situations. The general pattern is that an existing record in a Hosted Feature Layer with properly populated fields is being retrieved somehow into S123 (via Inbox or via URL scheme in a Dashboard) and, under certain ideosyncratic conditions, some populated values show up in the retrieved record as blank. If the record is re-submitted, these blank values will overwrite the existing correct values in the data layer. One example are text fields with input masks retrieved in the web browser version of S123. They are being linked to from a Dashboard. The input masked fields come in blank, but when the mask is removed they come in properly (this is the workaround in our case). Another example is 'time' control fields in a repeat (retrieved into the field app via Inbox). In this case the values on all sub-records (except the very first, which does show up) are treated as blank until the reviewer manually scrolls through all repeat records. If the reviewer does not do that and resubmits the survey, then blank values will be written to the source data. As you know these 'time' values are stored as text, so changing the field type to 'text' solves this problem; however in our case this breaks some other necessary functionality (for an unknown reason-- embedded javascript is involved). Both of these examples occur in QA/QC workflows where reviewers are retrieving records submitted by other users on other devices. So we just want to bring it to your attention, since the end result if unaddressed is that a normal review will actually corrupt existing data. Thanks! ... 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