Just tried it.
I was using the seasonal_decompose from statsmodel in python for a project. I have to say ASAP looks great!
Here is a link to her presentation: https://vimeo.com/221062931
It is pretty fascinating, I do recommend giving it a watch.
What is an appropriate smoothing is very context sensitive and I would like the consumer of the plots be in charge of that. Sometimes smoothing away the high frequencies or transients are exactly the wrong thing to do (for example, when you care about transient spikes)
I have seen more than enough damage done by plotting tools sneaking in a smoothing without informing the consumer. Especially so in the monitoring space. When the user expects raw plots it better be raw, and raw is a good default. Smoothening should be invoked explicitly.
We developed ASAP with the intend to complement, instead of replacing the raw plots. We view ASAP more as a "smart default" - if you were to expose a slide bar of different moving average window sizes that users could apply to their visualizations, where should a reasonable default be on that slide bar?
In addition, ASAP does not always choose to smooth the visualizations. In some cases (e.g. Figure C.1 in the arXiv paper) where the raw plots already have a few well-defined outlying regions and smoothing would only decrease the extent of such deviations, ASAP leaves the visualization unsmoothed.
Update: Hi Jeff!
To clarify, the main goal of ASAP is to automatically select a reasonable smoothing parameter for time-series. Moving average is already widely used for time-series visualization and dashboards, but setting the width of the window is a usually manual process.
If you're interested, our extended version of the paper (https://arxiv.org/pdf/1703.00983.pdf) contains some empirical comparisons of the moving average function with other smoothing functions like FFT and the Savitzky–Golay filter.