Throttle script filters

[ctwise]

Script filters fire for every key press. That is fine for lightweight script filters that can respond quickly but is a problem for heavy script filters that take significant time to operate. It would be helpful to support script filter throttling. This might be as simple as a checkbox ("Throttle requests"). It would work by waiting a short time between key presses, if another key is pressed the timer resets, if the timer expires the script filter is run.

 

It's possible to emulate this in a script but it's such a common use case it would be helpful to have it in Alfred.

[Andrew]

Alfred always waits for a single script filter object to finish before calling it again, so if it calls on the first character you press and takes a few seconds to reply, it will only get called again with the current query at this point (e.g. if you have typed 6 further characters, the script gets called with these 6 characters, not all the separate times inbetween).

[ctwise]

Alfred always waits for a single script filter object to finish before calling it again, so if it calls on the first character you press and takes a few seconds to reply, it will only get called again with the current query at this point (e.g. if you have typed 6 further characters, the script gets called with these 6 characters, not all the separate times inbetween).

 

That's good to know but if a script takes five seconds to return results and I type the query 'avengers', then I get script results for 'a' and ten seconds later I get script results for 'avengers' as opposed to five and a half seconds later for a timeout of 500 milliseconds.

[Tyler Eich]

David Ferguson helped me with this: http://www.alfredforum.com/topic/382-switch-back-to-please-wait-subtext-if-script-is-executed-again/

[jdfwarrior]

The only issue with timeouts would be that even the last character typed would fall victim to this. So if it took a little longer than expected to show the last set of results, it could fail and you get nothing as well. 

[untidey]

I wonder if Alfred could by taught to only fire off the script once a keypress timeout was met? So, instead of firing on immediate keypress, he waits for a very short time (30ms?) to see if another key has been pressed, only firing the script once no new keypress is registered. So, in the Avengers example, instead of firing on the press of 'a' it only fires once 'avengers' is fully typed, assuming you type 'avengers' quickly. Does that make sense?

 

I couldn't find conclusive data on how quickly users typically type but did come across Jakob Nielsen's findings that a 100ms response time is still perceived as instantaneous.

 

http://www.nngroup.com/articles/response-times-3-important-limits/

[Andrew]

I wonder if Alfred could by taught to only fire off the script once a keypress timeout was met? So, instead of firing on immediate keypress, he waits for a very short time (30ms?) to see if another key has been pressed, only firing the script once no new keypress is registered. So, in the Avengers example, instead of firing on the press of 'a' it only fires once 'avengers' is fully typed, assuming you type 'avengers' quickly. Does that make sense?

 

This is certainly a very interesting idea, and definitely something I'm willing to have a good think about after v2.0 is out. It might be worth reviving this topic and reminding me in the future

[Wes]

This is certainly a very interesting idea, and definitely something I'm willing to have a good think about after v2.0 is out. It might be worth reviving this topic and reminding me in the future

 

As you requested, the thread has been revived and you are reminded ;-)

[deanishe]

This is a very cool idea. I think 30 ms is much too short of a delay, however (that's 30+ characters per second!).

 

The optimal delay would be very user and workflow dependent. Some users type much faster than others; some workflows take much longer to return results than others. And the response time of the same workflow can be highly variable, depending on the state of what the workflow is leveraging (other apps, the OS, the network).

 

I think a decent compromise would be for workflows to be able to indicate a suggested minimum query length/change in query length (i.e. don't query with less than 3 characters or if fewer than 2 characters have been added/deleted), which would be honoured by Alfred until a timeout has been exceeded. The timeout would be decided by Alfred based on observed user input speed (i.e. Alfred might call the workflow after 250 ms for a touch-typist like me or after 500 ms for a hunt-and-pecker like my dad), or a user-specified value.

[johnjddoe]

Bump! I think this would be a really useful feature to have. At the very least, I think Alfred should not show out of date results - e.g. if you type 'avengers' and the script returns results for 'a', Alfred just ignores those results and then reruns the script with 'avengers'.

[mattsson]

Is there still no good solution for this? Why not just make it possible to set a throttling interval in the Alfred API when coding the workflow?

[deanishe]

Alfred 2.6, January 2015. In your Script Filter, click the Run Behaviour button.

 

You can choose whether Alfred should wait for or kill an already running script, and you can choose how long it should wait for user input before executing the script.

[mattsson]

I completely forgot about that screen. Thanks!