usage metrics dashboard: better refresh button

[toph-allen]

This PR makes some small changes:

• Renames "Clear Cache" to "Refresh Data".
• Captures the timestamp when the currently-displayed data was last updated, and displays it under the refresh button.
• Tightens the spacing on horizontal rules in the sidebar so the refresh button is always visible.
• Increments the version, so will cause a release.

The cache timeout remains set at 60 minutes. I had considered setting it to 30.

You can view this version at https://connect.posit.it/usage-metrics-dashboard-cache-button/

[jonkeane]

Moves the "Clear Cache" button to the top and names it "Refresh Data"

From a visual perspective / having things that folks should need to interact with at the top I think we should keep this lower down rather than at the top. I know before it was low enough that folks had to scroll to get to it, but maybe we can get rid of the hline there instead or some other way to use that space more efficiently without promoting cache refreshing to the first thing someone sees.

[jonkeane]

Thanks for this. A few changes

[toph-allen]

Moves the "Clear Cache" button to the top and names it "Refresh Data"

From a visual perspective / having things that folks should need to interact with at the top I think we should keep this lower down rather than at the top. I know before it was low enough that folks had to scroll to get to it, but maybe we can get rid of the hline there instead or some other way to use that space more efficiently without promoting cache refreshing to the first thing someone sees.

I moved it to the top for a few reasons, but yeah, to have it visible above the fold:

• In the user-feedback session I noticed that it was confusing for people to not see the latest data show up automatically when visiting the app. Having it visible makes it immediately understandable above the fold to users that the data aren't, like, live-updating.
• It gives people an easy out if a bad request somehow does get cached.

Additionally, I considered moving it to the title bar — that way it feels a little more like a meta app-level interaction and less like one of the core controls. What do you think about that?

[toph-allen]

@jonkeane I moved the button back down to the bottom, and removed the separators. I did think the separators enhanced clarity (between global filters and filters that apply to the outer / inner views only) but I don't think the regression is that significant, and it brings the "Refresh Data" control above the fold on my laptop's external display, in a non-fullscreen window, with the Connect UI showing, so that's a win in my book.

[jonkeane]

Frankly, both of these make it seem like maybe we should not have a cache at all. What's performance like without any cache at all? Is it possible for that to be delightful (the answer might still be no)? Are there things we need to improve in the Connect API that would make this delightful without needing to cache + communicate how that works to users?

• In the user-feedback session I noticed that it was confusing for people to not see the latest data show up automatically when visiting the app. Having it visible makes it immediately understandable above the fold to users that the data aren't, like, live-updating.
• It gives people an easy out if a bad request somehow does get cached.

[toph-allen]

@jonkeane You make a good argument for removing caching totally! I would be in favor of that, I think.

The feeling of slowness comes from a few things:

1. Some of the delay comes from reactable rendering all of the table rows, even ones that have not been paginated to yet. When viewing all content on server, e.g. for connect.posit.it, that's like 700 items (for me, an Admin user, at least), and that takes time. This is not helped by the app's current caching approach.
2. Some of the delay comes from parsing the JSON data into the data frame required for the plots. This is tangentially related to some of the connectapi stuff we've been discussing, but only tangentially — in this case the data really does have to wind up as a parsed data frame. There may be faster ways to parse this though.

Notably both are more significant problems for Admin users:

1. By default, Admin users see all content on the server, rather than just their content, so many more rows are rendered.
2. Admin users receive all hits from the server, whereas Publishers only receive hits for content they own and collaborate on.

As currently implemented, caching mainly speeds up interactions for users who are setting the date range back to a date range they have selected before, after selecting a different date range. From this perspective, yeah, I can totally see how having the caching, which necessitates a "Refresh Data" button, would be worse.

Another middle ground option is: keep the cache behavior but change it to a "session" cache, i.e. the browser's refresh button will clear the cache for a user. This means that in an individual session with the app, navigating around might be faster, but we wouldn't need the "Refresh Data" button, because the cache would be dropped when a new Shiny session begins, which happens upon browser refresh. I think this is probably the best quick win for caching-related stuff, and is really simple to implement.

[dotNomad]