Consider replacing `performance.interactionCounts` map-like with a `performance.interactionCount` number

[mmocny]

111 added a map-like structure for interactionCounts to the spec, but as we iterate towards an overall responsiveness metric and review developer feedback, I think it is worth re-considering the proposed interface to just use a simpler performance.interactionCount numeric value.

Background: The goal of separating interaction counts by type was for the purposes of treating interactions as distinct when it comes to responsiveness expectations. It is possible that interactions may need distinct budgets, e.g. keyboard should be 50ms and tap should be 100ms. This is already exposed via each event entry to event timing (by mapping event type via entry name to either keyboard/tap).

A total interaction count is needed to turn individual events into an overall average or percentile for a single page load, given that not all individual events are exposed (i.e. due to durationThreshold). Either way, whether you use distinct interaction budgets or not, you would not actually segment total interaction counts by type to compute overall percentile/average responsiveness.

Yet, we thought there may be some value to splitting out the counts. i.e. for reporting distinct interaction counts in order to compete a distinct "keyboard responsiveness" and "tap responsiveness" as auxiliary metrics. We also thought that total interactionCount is trivial to compute from by-type interactionCounts so there was not much cost to doing so.

But some complications that have arisen with budgeting in general:

• Events like click or input can be fired by either a keyboard or pointer. This distinction is not currently exposed to event timing so budgets are hard to calculate. It is also odd to consider a distinct responsiveness budget for the same event depending on how it was triggered.
• Usage of keyboard-based accessibility devices. It is odd to consider a distinct responsiveness budgets due to use of such devices.
• Feedback from UX researchers and developers that the expectations for keyboard/pointer responsiveness should not actually be distinct.
• Some early keyboard experiments that hinted at a need for lower budgets were re-visited, and we found that using the same pointer budget with the latest responsiveness definitions already did match expectations.

All this suggests we are unlikely to want to segment interactions by type. It is cleaner, simpler, and less ambiguous, to just expose a single interactionCount value.

---

Also: It may already possible to get keyboard and pointer interaction counts by just using eventCounts.

The one complication is Tap vs Drag, but these share budgets, and as an auxiliary metric this distinction may not matter. If it does matter, possibly you can already identify drags effectively by using counts of pointercancel:

function estimateInteractionCountsByEventCounts() {
    const ptrCounts = Math.max(...['pointerdown', 'pointerup'].map(t => performance.eventCounts.get(t)));
    const ptrCancel = performance.eventCounts.get('pointercancel');
    const keyCounts = Math.max(...['keydown', 'keypress', 'keyup'].map(t => performance.eventCounts.get(t)));
    return {
        'tap': ptrCounts - ptrCancel,
        'drag': ptrCancel,
        'keyboard': keyCounts,
    }
}

[nicjansma]

So far, in consuming this type of information in boomerang.js (RUM), a simple interactionCount value seems ideal. The count is needed mostly for calculating overall responsiveness metrics like the page's Interaction to Next Paint. It would be easier to consume as a single count, rather than having to enumerate each interaction type's counts.

All of the complications you list with splitting counts by type seem like a barrier to a map being useful.

At this point I'd be supportive of just an interactionCount metric, though I'd love to hear if there are any other use-cases that per-type counts will be useful.

[mmocny]

Thanks Nic for feedback, I'll take a stab at a wording change.

FWIW: we did discuss this as a WG and there were no comments against. I do suspect most folks just haven't been playing with this at all yet, and this is beginning to ramp up. So requests for exposing a per-type count may grow over time. Exposing a simple interactionCount doesn't preclude us from doing something more detailed eventually.