usage metrics dashboard: better refresh button

[toph-allen]

This PR makes two small changes:

• Moves the "Clear Cache" button to the top and names it "Refresh Data"
• Captures the timestamp when the usage data is fetched, and displays it under the refresh button

It also increments the version, so will cause a release.

Questions:

• Perhaps "x seconds/minutes ago" would be better? It uses the server's local time, which… like connect.posit.it currently shows 11:35 PM, and it's 7:35 PM here in NYC.

[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

[jonkeane]

Perhaps "x seconds/minutes ago" would be better? It uses the server's local time, which… like connect.posit.it currently shows 11:35 PM, and it's 7:35 PM here in NYC.

Perhaps, but unless it's easy to implement, let's not get stuck on getting this perfect. There are a variety of ways one could go about making this be localized (like https://stackoverflow.com/questions/45651789/changing-time-and-dateformat-to-show-correct-format-on-shiny-dashboard). If we can do that quick + easy let's do it. Could you timebox adding one of these and then do the simple thing below if you can't within that timebox?

But it also would be fine to add %z so that the offset is shown.

[toph-allen]

I'm just following your suggestion to show the time zone — anything else seems to get really fiddly (capture the browser's time zone and send it to the server).

[dotNomad]

I believe the checksums need to be updated in the manifest right?

[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.