@Prtksxna, I talked to Moriel and she says that when the button is in unavailable state, it can't pop a dialog. So we have a new plan (sorry about that). We'll gray out the button and just change the text of the on-screen message, as described above. Please use that message but show on page for clarity. (I've requested boldface to help people see it but maybe you have a better idea?) Thanks.

From the description above:

Next update permitted at hh:mm (timezone/location notation). Last updated hh:mm.
…
Last updated 2018-10-29 18:49 (Africa/Accra).

I would strongly advocate for using ago times and show the exact times on hover (as I have been showing in some other mockups). They are much easier to read and make sense of:

• Next update permitted in 22 minutes. Last update 8 minutes ago.
• Last updated 3 days ago.

@Mooeypoo @Niharika @aezell I rewrote this ticket. I had to revise it a bit after estimation. Until then, I didn't realize that we wouldn't start the 30-minute Lockout period until after the update had completed. That's fine, but it necessitates a new state for the communication system described in this ticket: the "Updating State". That's the state the system is in during the update process. So that forced me to reorganize this ticket to fully define the three stats, as above (a masterpiece of clarity in my opinion). But the only thing really added is the Update state .Do we need to re-estimate this or does 3 still cover it?

@Prtksxna I revised this ticket as described immediately above. I don't actually think this new state requires any new design elements—though no mockup is shown for the Updating State alone. Add one only if you think necessary.

From the description:

The user will need to refresh the page to use the Update button again.

@Mooeypoo and @MusikAnimal confirmed during the standup (1/2 Nov) that they'll be able to refresh the page automatically. Let's do this.

In T207911#4708371, @Prtksxna wrote:

From the description above:

Next update permitted at hh:mm (timezone/location notation). Last updated hh:mm.

I would strongly advocate for using ago times and show the exact times on hover (as I have been showing in some other mockups). They are much easier to read and make sense of.

Confirmed in the standup that we can use ago times and have them periodically updated. @jmatazzoni should I update the ticket with new text labels (per my previous comment)?

In T207911#4736639, @jmatazzoni wrote:

@Prtksxna I revised this ticket as described immediately above. I don't actually think this new state requires any new design elements—though no mockup is shown for the Updating State alone. Add one only if you think necessary.

In the same meeting we found out that we don't need to block the users' actions while they wait for a new report. This means that we might not need a separate waiting indicator (T207776) and can use this button to do the job for us.

Would something like this (with or without the animation) might eliminate the need for T207776? If so, I'll make designs for the error states too.

From the *description*:

…when the user requests a download, the system checks to see if the update is allowed. If it is, the system goes into Update State.

We discussed that it might not always be helpful to trigger an update whenever possible. We have two options instead:

1. Let the users download reports without updating until a certain time threshold, say 1 day, and after that fore updates.
2. Always let the user download reports without updating, but let them know clearly that the data might be old, with a call to action to update it now.

I am not sure if we reached a consensus during the meeting about which approach we'd like to go with. I'd pick option 2 because it keeps the user informed, and in control. What do you think @jmatazzoni @MusikAnimal @Mooeypoo?

@Prtksxna asks:

Confirmed in the standup that we can use ago times and have them periodically updated. @jmatazzoni should I update the ticket with new text labels (per my previous comment)?

I see that the "ago" format provides some measure of ease of use. But I am informed that changing to this would be work, particularly as it requires us to keep doing dynamic updates for short times. And since I am further informed that core features of this project (like the remaining four reports) are in some doubt, I can't approve that at this stage. So a) please leave date formats in the existing format and b) go ahead and write a ticket to change the date formats for this ticket and on T206576 to the "ago" format. If we can get to that I'll be happy to do so.

(You may need to define some rules around that unless they already exist. E.g., do we say "last updated 748 days ago," or is there some cutoff where the actual date becomes more useful again? Conversely, what is the phrasing for less than one minute? And how often do you keep updating if you are showing "10 minutes ago," etc. )

In T207911#4754819, @jmatazzoni wrote:

And since I am further informed that core features of this project (like the remaining four reports) are in some doubt, I can't approve that at this stage.

That makes sense.

So a) please leave date formats in the existing format

Done, not changing those, and update the other ticket (T206576)

b) go ahead and write a ticket to change the date formats for this ticket and on T206576 to the "ago" format. If we can get to that I'll be happy to do so.

T209910: Use relative time lengths instead of absolute time + timezone when informing the user about last updates

(You may need to define some rules around that unless they already exist. E.g., do we say "last updated 748 days ago," or is there some cutoff where the actual date becomes more useful again? Conversely, what is the phrasing for less than one minute? And how often do you keep updating if you are showing "10 minutes ago," etc. )

moment.js has sensible defaults here. Updating every minute should be fine, but I'd leave this up to the engineers.

Just a friendly note -- the "lockout" restriction in particular should probably be deprioritized, as it's really just a solution to one of those "good problems" that we might have further down the road. Ideally we'll continue to let people try to get the data they want, on-demand. After all, most events (judging by # of pages improved) should have fast-running queries that won't cause problems for other users.

The lockout functionality is a good idea but maybe not sprint-worthy until we add all the other metrics, and discover the "Update Data" queries are in fact a significant burden on our system. The job queue, after all, means everyone gets their data on a first-come first-serve basis, and right now that's a competition between about 10 or so people that make up our userbase. Clashes are unlikely in the near-term.

Sorry for not bringing this up sooner!