Latest Contributions by simoxu

Auto-populating / pre-populating data in the collection form could be misleading requirements from users which should be carefully evaluated and verified by the business analyst and designer. Please allow me to explain using my past experience. A few years back when ArcGIS Collector was just released, I was assigned a project to digitise some field data collection forms using ArcGIS Collector. It is easy right? to turn the paper-based forms into excel-like digital forms and install them on a smart device, then job done. Sure... until things like mobile data collection, offline/ editing, sync, cloud storage, history keeping and archiving, reporting, dashboard monitoring, etc these system components come up into the picture, people started realising it was actually a new system solution for a specific field work, not just changing the media of the forms from paper to pixels. This is important to let you think out of the box and only focus on their desired result and not restricted too much to their existing ways of doing things in the field. Now let's talk about the auto-populate / pre-populate fields. My customer's field work involved property damage assessment, in their forms they needed to fill the information of the property (house, land or business) they were about to assess, many of those fields were repetitive on different forms and that was a time consuming process in the field. To make things worse, their use case was in a disaster response circumstance and the forms really were supposed to be filled quickly. So they wanted those repetitive fields and as many as possible other fields to be auto-populated in the digital forms. It is a valid and reasonable requirement from a user's point of view, right?  Of course it is because the forms are the interfaces between users and the system, and they want some fields in the form to be magically auto-populated. But when we analyse the requirements and design the system, we have to ask what that mean? what they really want? In my case, the users wanted to auto-populate the following category of the information: The residential property information (location, rooms, building material info, capital value, owner info etc.)  Business details (business register number, business name, value, contact details etc.)   Assessor info For point 3, it was not a problem for Collector.  because when you enable tracking for the hosted feature layer, collector will fill out this information with the named user's information. see the following link if you don't know how. Manage hosted feature layers—ArcGIS  Help | ArcGIS For point 1 and 2, what did the users really want? what did auto-populate mean here? for the users, in this case they only wanted contextual information for the subject of the assessment, and auto-populating is only one way to bring in the contextual information about these properties and businesses that were about to be assessed. Most importantly, these information should already exist somewhere, why should the users (mainly field works) collect them again?  What if we replacing auto-populating with popping up?   After discussing these questions  with the users, we agreed upon:   Some fields in the original forms did not have to be in the digital form as long as they could get the contextual information for the assessed subject. Only the assessor and assessment timestamp were the fields which needed to be auto-populated. Locations and associated contextual information were prepared (pre-populated), which gave another benefits such as reducing the human errors in data collection,  avoiding data redundancy and maintaining information consistency. Remove any fields that were not absolutely necessary for the mobile data collection. The most common mistake I’ve seen in data collection is that users are too “greedy”, they want to put all the fields in the final report in the data collection form, this will cause disastrous consequences in the mobile data collection, which need to be light-weighted and the less fields the better. This is not only from technical consideration, but also an operational consideration. Generate the report at the system backend and do it in the office where we had access to the internal database, and we had all the other information needed to create any sort of reports required.   As a result, most of the auto-populated fields were replace with contextual information when assessing the object: Contextual info for the house Contextual info for the business:   If there is one word you'd like to give away, It will be: don’t auto-populate existing data, make reference or link to it instead. ... View more