Define audit log event behavior when there are multiple questions on one screen

TL;DR: the specification for client audit logs is incomplete because it does not formally define what question events are and when they should be logged in the multiple-questions-per-screen case. I think it makes sense to wait until someone is ready to implement this before defining that behavior.

The ODK XForms spec includes a side spec for client audit logs. These make it possible to capture a CSV sidecar file with the user actions taken while filling out a form in. Currently, this is only implemented in Collect. See also the Collect documentation.

In the ODK ecosystem, there are generally two different ways to display questions: each on their own screen or multiple on a screen. For Collect, the default is one per screen. It's possible to have multiple questions on a screen by using the field-list appearance. For Enketo, the default is all questions on a single screen. It's possible to display questions on separate screens using the pages style.

When there is one question per screen, it's straightforward to define a question event as starting when the user gets to that screen and ending when the user leaves that screen. This gives survey designers a good sense of how a user navigated around a form and how long each question took.

It's less clear what should constitute a question event in a single-page context. I currently think that what makes the most sense is to consider focus only. That is, a question event begins when a user first interacts with a question's UI and ends when the user interacts with a UI element that does not belong to that question. That strikes me as the most consistent with the single-page model.

This is now what Collect does now. Currently, for basic audit logging in Collect, if questions are in a field list, they will not individually show up in the audit log. Each time the field list is visited, there will be a field list event with the time the user entered the field list and the time the user exited the field list. For audit logging with change tracking, when a field list is visited, a question event is logged for each question in the field list whose value has changed. The start and end times for those events are the time that the user first saw the field list and the time that the user exited the field list. That means that it's unclear how much time was spent on each question and whether a user went back and forth between questions on a single screen.

Ideally, Collect would provide more granular information for questions in field lists and this would match how clients that default to single-page presentation define question events.

I don't think this is a priority given all the other projects going on but I wanted to make sure we have background on the issue for when one of the multiple-questions-per-screen-by-default clients starts implementing the audit log features. At that point it will be critical to have a formal spec for the question event behavior.

Ideally yes, although in practice the underlying platform UI framework may make the latter more or less easy. eg in most cases a text entry UI widget will (or can) receive a 'lost focus' / 'keyboard dismissed' / etc event when this happens. But in other cases it may simply be that some other UI object receives the next event from the main UI thread, and short of intercepting all these events it could be quite hard to backtrack and determine who was previously receiving UI events (and hence 'lost focus'...)

[which is one of the reasons I've been looking into triggering these of xform-value-changed events, ie when the actual instance XML gets updated, as opposed to the specific UI widget that have precipitated it. Note, my particular usecase is specifically in regards to change tracking, not the general audit log in general, which can be more client specific]