OTs and feature detection

[Yoav Weiss]

Hey folks,

One point that was raised when talking to an OT partner - there have been cases in the past where an OT was run without a feature detection method, making it hard for OT participants to measure the benefits of the OT. 

The specific example here was Early Hints, where there was no way to detect if preconnect hints were having an impact on the user, and hence hard to split the experimentation population apart.

Would it make sense if we added a requirement to the process/tools for OTs to make sure that a feature detection mechanism is in place?

Cheers :)

Yoav 

[Chris Harrelson]

+1

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfVtHFcigQ_WKKgo6GQMuYQAzEz4HP-AB3MvE%2BwqDzqqCQ%40mail.gmail.com.

[Mike Taylor]

+1, good idea. Maybe we can eventually document common patterns.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZtw5%2B0GOfWDX02SqozjqnwGuCS1LWUPu6x_A6VS%2BNUVfg%40mail.gmail.com.

[Domenic Denicola]

I'm curious what this would look like. If the API doesn't allow feature detection normally (e.g., an HTTP header), are you suggesting we add an Origin Trial period-only JavaScript API or something to allow such detection?

That seems like an interesting thing to do in individual cases, e.g. cases where performance measurement is important like you mention. But I'm not sure it needs to rise to the level of policy...

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/9f0a7977-12dd-4b84-1e24-936b05ada3e7%40chromium.org.

[Rick Byers]

Yeah why is this a concern for OTs and not shipping features generally? I thought at one point we had a discussion of feature detection in the I2S template. Right now I think the closest we have is the description of "activation risks" field in chrome status:

"Will it be challenging for developers to take advantage of this feature immediately, as-is? Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?"

Perhaps we should just include a mention of feature detection there?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAM0wra87C-gRcEygZgbqqfruCWDML_bv%3DYVUNHK8v%3DOOkzMkZw%40mail.gmail.com.

[Yoav Weiss]

Including a mention of feature detection as part of "activation risks" makes sense.

I think this is a bigger concern for an OT compared to shipped features, since for an OT developers cannot rely on UA sniffing in order to deduce supported features. That becomes worse for trials that are Finch based. (as IIRC the Early Hints trial were)

At the same time, it's probably a good idea to insist on feature detection across the board.