[TTS] Configure before-scroll timing and tune and coordinate initial tap delays |
|||
Issue descriptionWe still need to enable or configure the before-scroll logic that allows a tap that's immediately followed by a scroll to be ignored. This is complicated by having a couple of other delays and a work task that all may happen during initial tap processing. Background: We reworked the "before-scroll" logic as part of the CL that moved ML feature collection to inference time (https://codereview.chromium.org/2894913003). That CL set up an experiment flag to use to configure the before-scroll tap suppression feature, but we never set up an experiment, so the logic is effectively disabled. Tap on previous tap-selection (https://chromiumcodereview.appspot.com/2963013002/) was done recently, and possible-tap-near-previous was added around the time the Internal State Controller was added to handle invalid taps. Plan: For Before-scroll it's probably best to just look at the data we collected and pick a value (probably in the range of 100-200ms) to delay and put that into the code, removing the experiment flag. This delay is done in parallel with running the suppression logic. We should check the two other delays: A) WAITING_FOR_POSSIBLE_TAP_ON_TAP_SELECTION: The tap on previous tap-selection delay is only done when not in IDLE, but it runs before any other processing, so it should be tuned to be short and possibly not done in other states. B) WAITING_FOR_POSSIBLE_TAP_NEAR_PREVIOUS: The wait for possible retap happens when the selection is cleared, so we should check that this doesn't interfere with these other cases.
,
Jul 13 2017
I'm not sure this is something we need UX on. Donn, you mention we can "look at the data". Can you link out to that? What do you think is best?
,
Jul 13 2017
I just took a quick look at the data: We have a profile of usage for the duration between a tap and subsequent scroll. The usage increases up to about 85ms and then starts to fall off. However this only represents about 5% of the tap/scroll-dismiss actions. https://uma.googleplex.com/p/chrome/histograms?endDate=20170712&dayCount=28&histograms=Search.ContextualSearchDurationBetweenTriggerAndScrollNotSeen&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial Scroll-dismiss is in a virtual tie for most popular way to dismiss the panel (along with tap -- https://uma.googleplex.com/p/chrome/histograms?endDate=20170712&dayCount=28&histograms=Search.ContextualSearchExitPeeked&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial). So the above 5% is probably represents 2% of all dismissals -- seems significant. I'm not sure how to interpret this data, but here's my thinking. 85ms is too short for an intentional user gesture, so these represent the kind of unintentional tap-scroll actions that we've hypothesized (or there's some lag in the system compressing the timings). Since the frequency of these starts falling off we can probably capture a reasonable number of them by using a delay somewhat larger than 85ms, say 100ms. The long-tail above this range probably represents intentional user gestures to dismiss. So I think we should try to pick something above 85 and below whatever UX thinks is a noticeable delay. My recollection is that 200ms delays are getting pretty noticeable, so something in the 100-200 ms range seems good. We can leave the experiment flag in so we can tweak this via experiment if that seems useful. Then when we get a UX person onboard we can review this along with the general UX and suppression discussions. How does that sound? Theresa, thanks for reminding me about getting UX input -- I'd forgotten about that!
,
Jul 13 2017
I think we should operate under the assumption that we'll be UX constrained for the foreseeable future. So we should be proactive and then go to UX to review once we have something. I like the experiment of tweaking this with a finch config. Starting with 100 sounds fine. I might even push it a bit further to 150 and see how it feels.
,
Mar 19 2018
I don't think this is a priority anymore, removing milestone. |
|||
►
Sign in to add a comment |
|||
Comment 1 by twelling...@chromium.org
, Jul 13 2017