Minimize user-percepted interaction delay on the client

[dumblob]

Currently there is some delay (>150 ms, for bigger tables or complex widgets it's several hundred) which gets annoying.

Maybe employing the caching strategy from Riffle could make things much snappier and actually make Grist easier to maintain (mainly by avoiding growing API on the client side)?

Feel free to take a look at the Riffle approach in general - it has some interesting properties.

[paulfitz]

Thanks @dumblob, Riffle is definitely interesting. We had read some related papers on it a while back, and the reminder is useful. (Makes me nostalgic, I did a postdoc at CSAIL)

Just to be clear, the >150ms delay you see is between which two events? Interaction delay sounds like perhaps the delay between e.g. pressing enter after having written a value in a cell, and the spreadsheet updating based on that value, is that it? Or is it a different interaction.

[dumblob]

Thanks @dumblob, Riffle is definitely interesting. We had read some related papers on it a while back, and the reminder is useful. (Makes me nostalgic, I did a postdoc at CSAIL)

Awesome! I like the works.

Just to be clear, the >150ms delay you see is between which two events? Interaction delay sounds like perhaps the delay between e.g. pressing enter after having written a value in a cell, and the spreadsheet updating based on that value, is that it? Or is it a different interaction.

Yes, I meant user triggering something and getting a non-instant response of the system (e.g. clicking a button opening or closing something, or clicking a link and waiting for "it" to appear, or pressing Enter after editing a cell and waiting for everything to update accordingly, etc.).

In other words I mean the end-to-end latency (e.g. as measured by a 60+fps camera - modern iPhone shall be good enough for such measurements) and I am well aware of the latencies keyboards and mice contribute to it (therefore I have a lower-latency keyboard :wink:).