On our general process for deciding to ship features? We tend to do UXR for specific features (not general processes), and (as you know) that tends to implicate PII unless meticulously scrubbed.
-
-
Replying to @slightlylate @edent and
the Origin Trials framework intends to publish what it can from the surveys we conduct, but require large enough sample sizes to be psudonemous. Not all trials reach that level.
1 reply 0 retweets 1 like -
Replying to @slightlylate @edent and
But again, those trials are specific to a particular proposed feature, rather than the overall process.
1 reply 0 retweets 1 like -
Replying to @slightlylate @edent and
I'd also like to note the counterfactual: traditional working groups do not solicit or require feedback outside the set of people who are members of a particular SDO. This process is casting the nest wider and requesting more input than traditional standards development ever did
1 reply 0 retweets 4 likes -
Replying to @slightlylate @edent and
So I hear you on research; we're working to move the entire platform to a more evidence-based approach, and it's worth asking how the detractors of these tools would prefer things be structured instead. Is the alternative conference-room "consensus" from a preordained clique?
1 reply 0 retweets 1 like -
Replying to @slightlylate @RickByers and
1. Have a cool idea 2. Speak to real users and see if it meets a user need 3. Publish the (vague) user research and start discussing with peers 4. Design and iterate based on feedback 5. Test with users. Pass/Fail based on beta testing 6. Publish test results 7. Etc.
2 replies 0 retweets 1 like -
Replying to @edent @RickByers and
You're looking for Origin Trials, which we are unique in running:https://github.com/GoogleChrome/OriginTrials …
1 reply 0 retweets 1 like -
Replying to @slightlylate @edent and
Yep. You have to have something to trial with users in order to do user research, thus intent to implement!
1 reply 0 retweets 4 likes -
Replying to @domenic @slightlylate and
I mean... No... That's not how user research works. The toast project has found what people are already using. But has done no research to seek the opinions of those users or devs.
1 reply 0 retweets 1 like -
I think there's a misperception about ordering here. I2I is *super early* in the process, which we are making as public as possible as early as possible. There's both time to do the research and change course, all of which will happen in full view.
1 reply 0 retweets 1 like
From your blog post, it seems as though there's an assumption that implementation is late-stage, an for browser teams that aren't as evidence-driven, maybe that's true? But for us, getting some code flowing is key to testing. It's very, very, very far from the ship moment...
-
-
Replying to @slightlylate @edent and
...which is demarked by a separate set of emails ("Intent to Ship"). There's a high bar for I2S threads to clear vs. I2I, which is more of an FYI to the wider world, particularly owners of code in the affected directories, that someone is noodling in this direction.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @edent and
You can see the voting (and frequent push-back) on I2S threads here: https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Ship%7Csort:date … Sometimes these are folded together ("Intent to Implement and Ship"), but that's discouraged aside from trivial additions.
1 reply 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.