I'd like the ability to have 'smart' form entry with Collector. For example, if field A equals 'True' then field B, C and D do or do not show up for entry.
Maybe this kind of "intelligence" or "awareness" could be implemented at geodatabase level and managed not only in collector but also in other editing tools (web app, AGOL etc) ?
This is a process known as skip-logic or conditional branching or branch logic. We are currently trying to work through options for implementing Triggers and Stored Procedures on the SQL Database side to accomplish this but our efforts and research thus far seem to indicate we almost need a SQL Developer just to write and maintain these because of sheer numbers and complexity. Leveraging this type of functionality is huge from a QA/QC perspective because it reduces errors. From the user friendliness side it will make their workflows that much more intuitive and leave them happier because they can select from a list of 6 values that are relvenat based off a previous selection rather than having to find the needed value in a much larger list. Great post glad to see it's being considered just hope it gets enough attention.
Our organization is looking to deploy an enterprise collection application like Collector, and skip logic would be extremely valuable. A quick Google search for data collection apps shows this is a standard feature on other similar apps. This functionality greatly enhances the quality and integrity of data at the time of collection, reducing time & resources required to QA it later. Coupled with the better geospatial abilities of ArcGIS and ArcServer integration, this could really set Collector apart from other apps.
Also, the ability to have some basic validation would be really helpful (i.e., if field A is not filled in, require that field B be filled in; the ratio of field A to field B cannot be greater than a certain number). Right now for us to get that kind of functionality we have to break out the full Runtime SDK for this, which is over-kill for a lot of these projects.
I agree that this would be a great addition to the collector apps functionality. Our users are currently scrolling through multiple fields to collect the correct data. With a smart form solution this could be solved by assigning specific fields to show through the selection of another field.
Smarter data collection forms are on the 'Planned' feature improvements coming to Collector app in the future. See the Sneak Peek section, Sneak peek—Collector for ArcGIS | ArcGIS.
To implement lookups in collector we need to create database domains. This can be better done through the software using xml definition schemas. Another method is to use xls as in forms.
No need to waste considerable time on the data structure unless its used that way at source and most of the time it isnt, its just for collection. Using a sledgehammer to crack a nut
Working for a Florida Water Management District, we use this app to capture, review, repair, and report on various problems encountered when inspecting our flood control system. Collector is perfect, except for the lack of branched logic. We are currently using a weird hybrid of both Collector and Survey123 (pointed to the same database), which is not ideal. We are VERY EXCITED about the idea of branched logic being implemented in or supported by Collector.
As I've said many times before, we need Collector123. Forms are great in Survey123, but the maps suck. Maps are great in Collector, but data collection is clunky compared to the smart forms in Survey123.
