@MusikAnimal @Mooeypoo the mockup animation @Prtksxna created (go to the menu, select Pages Created, then select CSV) shows the progress bar going through various phases like "Calculating Contributions" and "gathering data"... These provide a sense that progress is happening, though of course do not provide actual units of progress. Or rather, they are units, but not in any measured way.

Anyway, is this possible for these updates? If so, can you say what they'd be? How does that get programmed in? Or will we be silent about our updating? And if we are silent, then how does the progress bar know how much progress to show? Should @Prtksxna be showing something more akin to a spinning wheel, just to denote "activity" rather than "progress"?

@Prtksxna, I see you added the legend ""Update timed out" to the Timed Out message. I wrote the heading for that to be "This process took too long and was stopped." In other words, I was assuming that "timed out" is somewhat of a piece of software jargon so I wrote in a way that would not require users to know that term. So, strictly speaking, the "Timed Out" legend is redundant.

Did you add it because you feel that the more descriptive message was not clear enough? Or just from habit? I.e., do you think both are necessary? If so, there's nothing wrong with what is there. But unless you feel strongly that the user needs to see the words "timed out," i'd drop that and elevate what is now the second message, please. Thanks

Hmm, well, it's quite tricky, but a proper progress is possible. The first thing we do is check what wikis we need to query. We then loop through each wiki, one by one. That'd be the biggest chunk, and hence would make sense to report "Processing 5 wikis out of 10" (or whatever).

This would be really neat, but no such infrastructure exists. We'd either need to implement a database-level tracking of the progress, and have the client continually query an API endpoint that reports the progress (probably the easiest, but still a lot of work), or implement some form of server-sent events (the more proper way). Symfony provides some things for event streaming ( https://symfony.com/doc/current/components/http_foundation.html#streaming-a-response ) so maybe it's not as bad as it sounds.

Overall I wouldn't consider this anything critical (since you said organizers are OK with things being slow?), but it'd certainly be fun to build :)

I don't think we can accurately build an actual timer. To do so, we'd need to know how long the process will take and what portion has already been completed.

With SQL queries and other network/application vagaries, there's no reasonable way to know how long an update will take without actually doing it.

I think time is much better spent showing the user a simple spinny thing and a message that the updates are happening and using the rest of the development time making the queries as fast as possible so the user has to wait less.

The designs look like your normal Bootstrap progress bar animation. If we do send back the client where we are in the loop (wiki 5 out of 10, etc.) then a progress bar will make sense (just pure animation, no timer). An example of what I'm talking about https://tools.wmflabs.org/massviews/?platform=all-access&agent=user&source=category&target=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCategory%3AAmerican_Revolutionary_War_task_force_articles&range=latest-20&subjectpage=1&subcategories=1&sort=views&direction=1&view=list

! In T207776#4703919, @MusikAnimal wrote:

The designs look like your normal Bootstrap progress bar animation. If we do send back the client where we are in the loop (wiki 5 out of 10, etc.) then a progress bar will make sense (just pure animation, no timer). An example of what I'm talking about https://tools.wmflabs.org/massviews/?platform=all-access&agent=user&source=category&target=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCategory%3AAmerican_Revolutionary_War_task_force_articles&range=latest-20&subjectpage=1&subcategories=1&sort=views&direction=1&view=list

Is that easy to do Leon? If it's easy, then that's fine. And the numbers will be, what, wikis? Is that it? What if the user specified only 1 wiki? Then what does the progress bar do?

If we are counting wikis and there's no notion of time left, then it seems fine.

In T207776#4703982, @aezell wrote:

If we are counting wikis and there's no notion of time left, then it seems fine.

What if there is only one wiki defined for the event? Will the bar, I hope, go halfway right away and then pause while doing the diagonal line animation? (I.e., it won't not start and then just jump to the end when done, right? The diagonal line animation here is the main point of this—it's what lets you know you're not stalled.)

In T207776#4703982, @aezell wrote:

If we are counting wikis and there's no notion of time left, then it seems fine.

That is exactly what I was hoping for. Just some idea of progress (and none of time). If that is possible it'd be better than just saying wait till this happens.

If we decide that this isn't possible we can use the standard 3-dot loading indicator — https://codepen.io/Volker_E/pen/yqNXMe (T75972). Will update the mock once we have a decision 😊

In T207776#4703078, @jmatazzoni wrote:

Did you add it because you feel that the more descriptive message was not clear enough? Or just from habit?

This was an oversight by me, sorry! Fixed now.

@prt, as per yesterday's meeting, what is the plan for indicating "activity" (as opposed to progress)?

@Prtksxna and I were discussing these and other questions:

• What happens if you leave the page? Does the process terminate or not?
• If the process does terminate, we should have a warning.
• If the process does not terminate, we should create a terminate-process button.
• Let's not do the multiple event thing. That seems like too much.

In T207776#4711378, @jmatazzoni wrote:

• What happens if you leave the page? Does the process terminate or not?

The way I understood this is that with the current architecture, yes, the process would terminate. However, we intend to make this a background process as part of the job queue work we've discussed. Once that is available, this could become a queued process that wouldn't require the user to stay on the page.

Here are my notes from yesterday's team Discussion meeting. Please look them over and make sure I got these right.

• Yes, count on VPS functionality for release #1 of Event Metrics.
• If user leave the page after starting an update, the process keeps updating.
• If the closes the page and then comes back, we can resume showing the "updating" message.
• Can we refresh the page information when the update is complete? Yes, we can refresh the messaging and the metrics (whether the page actually updates is a different question).
• What happens when a query times out? Do we still have the old data or has it been replaced with new? It’s possible some things would update and some not on the page, but the timestamp would not change. Moriel asks if we an store and only apply at the end? Leon is not sure. Is going to look it up.
• Do we need an abort function? Can we do that? We can, but adding it would have to be a new ticket and we can’t see a good reason for aborting given the answers above.
• We can update the timestamp on the page every minute if we want.

Updated T207911: Inform users as to whether Updating is currently allowed or blocked based on the discussion in said meeting.

A few concerns:

• There is actually another state before "Updating", which is "Pending" (or "Queued"). I assume we want a modal for this, too? Using the existing copy, it looks a little bland:
  
• Super duper minor nitpick -- Is "Metrics" the right word in "Metrics updating..."? As I understand it, metrics are like the type or standard of measurement, such as "Pageviews", "Pages improved". Each metric has a value, and those are what is being updated. Right now we use the message "Please wait, currently crunching the numbers..."
• There are two error states -- timed out (which we've covered here), and your generic "unknown error". For the latter, I've gone with the existing copy:
  
  Hopefully this error will never be shown!
• For the "timed out" error, the message we've proposed here is a bit misleading. Reducing the time period will certainly help, but reducing participants, categories, etc., possibly will not. I suspect event organizers will be at a bit of a loss in this scenario. They doubtfully will change the duration of their event to accommodate our system, especially after the event has already started? So I propose a more generic, open-ended message:
  
  I also think we should allow them to try again. In some cases it will work on subsequent tries, thanks to query caching. Furthermore, I suggest we offer the option to report the issue, but not imply it is something that is required, as we automatically receive an email detailing what went wrong.
• In all states, the user is able to close the modal. I have made it so that the "Update data" and related buttons/messages match the current behaviour. So for instance during the "queued" state you'll see:
  
  They are not able to navigate to the Edit List page, or anything that would require creating a new job.

Thoughts? I've got my suggested changes above implemented, and can demo it on staging if you'd like.

In T207776#4832532, @MusikAnimal wrote:

A few concerns:

• There is actually another state before "Updating", which is "Pending" (or "Queued"). I assume we want a modal for this, too? Using the existing copy, it looks a little bland:

So, if I understand, Pending comes before Updating and it means the job is waiting its turn to be processed? I have no objection to adding another state—unless it makes this job more time consuming or complex (in which case I'm against it)—but i have to ask: is this a distinction with a difference? To the person waiting, what is the value of seeing two messages instead of one, both telling him to wait? Is it a progress indicator of sorts? Can the job fail during the Queued stage and so the user has more insight? What is your thinking? Because personally, if you tell me that my job is waiting rather than being done, it just sounds a bit frustrating. Who am I waiting on? Why doesn't the WMF buy more processors?

As to language, assuming there is a good use case for this message, tell me what it is and I'll understand what the language should be.

• Super duper minor nitpick -- Is "Metrics" the right word in "Metrics updating..."? As I understand it, metrics are like the type or standard of measurement, such as "Pageviews", "Pages improved". Each metric has a value, and those are what is being updated. Right now we use the message "Please wait, currently crunching the numbers..."

Thanks for the note but unless I'm missing something the only things we're updating here that aren't "metrics" aren't "numbers" either (e.g., page titles, lists of files uploaded...). Why don't you change the label to "Updating data." I'll note that in the Description.

• There are two error states -- timed out (which we've covered here), and your generic "unknown error". For the latter, I've gone with the existing copy

Good to know. Thanks. As to the language, two things:

• Let's please avoid words like "Failed." How about "Unknown error" or "Something went wrong" for the heading. (Either way, please remove "Something went wrong" from the text of the message; it's redundant.)
• In the message, can we give the user an indication of what they should do? Should they "try again" (as below)? Should they "Wait for x minutes and try again"? What?

• For the "timed out" error, the message we've proposed here is a bit misleading. Reducing the time period will certainly help, but reducing participants, categories, etc., possibly will not. I suspect event organizers will be at a bit of a loss in this scenario. They doubtfully will change the duration of their event to accommodate our system, especially after the event has already started? So I propose a more generic, open-ended message: I also think we should allow them to try again. In some cases it will work on subsequent tries, thanks to query caching. Furthermore, I suggest we offer the option to report the issue, but not imply it is something that is required, as we automatically receive an email detailing what went wrong.

A lot of issues here; I'll take them in turn.

• If the problem is that there are too many pages, then how is it that reducing the size or number of categories won't help?
• They won't reduce the time period if it is a true event, it's true. But remember that Event Metrics wants to be useful for online events. What if the event in question is really massive, like Wiki Loves Monuments: might users not work around the limitations by breaking reports into smaller time periods? Or what if someone was just trying to use EM to get stats on a category overall (as I know for a fact Bluerasberry wants to do) and lists the event as covering the last 10 years ? Then might this not clue them that they are asking too much?
• Yes, I like the suggestion of inviting them to try again. Thanks.
• If reporting the issue is not necessary or helpful let's not make the users work. We can say nothing, or reassure them by saying "Your issue has been reported." Is it helpful for users to report or not?
• Please respond to these points and then we'll decide on final language .Thanks!

• In all states, the user is able to close the modal. I have made it so that the "Update data" and related buttons/messages match the current behavior.

Please do not implement either the on-page messaging ("The statistics are waiting...") or the button name change. These are unnecessary and conflict with the messaging system devised in T207911.

So for instance during the "queued" state you'll see:

They are not able to navigate to the Edit List page, or anything that would require creating a new job.

Graying out the Edit List button should also be unnecessary, since going to the Edit List does not—and should not—update the data there. That page should work just like the Edit Summary page, which is to say the data is updated when you hit the Update Data button or when you Download Reports. All the messaging is keyed to those assumptions. Again, see T207911 if you want to understand the system that has been crafted for this.

@MusikAnimal, add to the above that I'm noticing your dialog boxes don't match @Prtksxna's designs. Prateek please provide guidance as necessary:

• The font for the message title/heading looks too small
• Prateek specified "OK" not "Close" for the buttons. I don't care which one is used but I assume we have a standard (do we?). If so, we should go with that.
• Your dialog boxes are also wider. Again, I don't have an opinion about the optimal size but @Prtksxna might.

Thanks for the thorough replies! I'll go through one by one:

In T207776#4832840, @jmatazzoni wrote:

So, if I understand, Pending comes before Updating and it means the job is waiting its turn to be processed? I have no objection to adding another state—unless it makes this job more time consuming or complex (in which case I'm against it)—but i have to ask: is this a distinction with a difference? To the person waiting, what is the value of seeing two messages instead of one, both telling him to wait? Is it a progress indicator of sorts? Can the job fail during the Queued stage and so the user has more insight? What is your thinking? Because personally, if you tell me that my job is waiting rather than being done, it just sounds a bit frustrating. Who am I waiting on? Why doesn't the WMF buy more processors?

As to language, assuming there is a good use case for this message, tell me what it is and I'll understand what the language should be.

Yup, pending comes first. In most cases this will last but a second or two, but it could be longer. I think of it like https://quarry.wmflabs.org. It's telling you your job is queued up or is currently running. I don't know if this is that valuable to the user, but it's a bit more transparent, I guess? The job would not fail during the queued state, only when it is ran.

Thanks for the note but unless I'm missing something the only things we're updating here that aren't "metrics" aren't "numbers" either (e.g., page titles, lists of files uploaded...). Why don't you change the label to "Updating data." I'll note that in the Description.

"Updating data" sounds fine. I was just thinking in analytical terms, where "updating metrics" would in a literal sense be changing the types of data we're showing, when we're updating the values for each metric. This is going off of terminology I see the Analytics team using -- I'm no expert! And in our code, "Metric" means the types, too. Not a big deal, either way.

• There are two error states -- timed out (which we've covered here), and your generic "unknown error". For the latter, I've gone with the existing copy

Good to know. Thanks. As to the language, two things:

• Let's please avoid words like "Failed." How about "Unknown error" or "Something went wrong" for the heading. (Either way, please remove "Something went wrong" from the text of the message; it's redundant.)
• In the message, can we give the user an indication of what they should do? Should they "try again" (as below)? "Wait for x minutes and try again"? What?

I like "Something went wrong" -- both friendly and accurate. They can try again, but in this case it's probably something that went horribly wrong where subsequent tries wouldn't help. They'll likely just have to wait for engineers to come in and fix the bug.

For the "timed out" error

• If the problem is that there are too many pages, then how is it that reducing the size or number of categories won't help?
• They won't reduce the time period if it is a true event, it's true. But remember that Event Metrics wants to be useful for online events. What if the event in question is really massive, like Wiki Loves Monuments: might users not work around the limitations by breaking reports into smaller time periods? Or what if someone was just trying to use EM to get stats on a category overall (as I know for a fact Bluerasberry wants to do) and lists the event as covering the last 10 years ? Then might this not clue them that they are asking too much?

Adding categories may reduce the number of pages (say there were no categories beforehand), and adding participants can help (say there were no participants). On the other hand, removing participants may not help, say if they remove 100 of them, but there is still one remaining that has edited 100+ wikis that's slowing everything down (we have to scan each one if they've selected "All wikipedias"). I think reducing the wikis will always help. So basically, we'd have to add a bunch of complicated logic to provide more accurate suggestions, or provide something more open-ended. My thought is that for now, our strategy will have to be to wait and see what happens with real world events, and adjust our code and user-facing language accordingly. T205322 will provide more answers, too.

• If reporting the issue is not necessary or helpful let's not make the users work. We can say nothing, or reassure them by saying "Your issue has been reported." Is it helpful for users to report or not?

My hope is that with a persistent problem they may be able to provide more context when they reach out to us, so that we can better understand how to accommodate their needs. The query or line of code that caused the job to fail will be made available to us automatically. We can certainly say "Your issue has been automatically reported", that is accurate.

• In all states, the user is able to close the modal. I have made it so that the "Update data" and related buttons/messages match the current behavior.

Please do not implement either the on-page messaging ("The statistics are waiting...") or the button name change. These are unnecessary and conflict with the messaging system devised in T207911.

I think we should do this piecemeal and handle T207911 next. The on-page messaging I speak of is identical to what we have now. I can implement the copy changes in T207911 along with this, that's easy, but the "locked out" state is a fair chunk of work. I have some reservations about it too, I'll comment on that task.

Graying out the Edit List button should also be unnecessary, since going to the Edit List does not—and should not—update the data there. That page should work just like the Edit Summary page, which is to say the data is updated when you hit the Update Data button or when you Download Reports. All the messaging is keyed to those assumptions. Again, see T207911 if you want to understand the system that has been crafted for this.

The Edit List is a little weird... not all the data is precomputed. The page IDs are, but the revisions (edits) are fetched on-the-fly, since we can feasibly store that information in our database. We don't need to make the Edit List fetch new page IDs -- leave that to the "Update Data" button (or downloading reports), but it does need to go through the job queue (which it doesn't, yet...) because they are long-running queries. We don't want multiple jobs running in parallel, hence why the Edit List button is grayed out. This is the current behaviour in production.

In T207776#4833004, @jmatazzoni wrote:

@MusikAnimal, add to the above that I'm noticing your dialog boxes don't match @Prtksxna's designs. Prateek please provide guidance as necessary:

• The font for the message title/heading looks too small
• Your dialog boxes are also wider. Again, I don't have an opinion about the optimal size but @Prtksxna might.

Sorry about that. I'm not sure what font sizes should be used, or the widths. To me it looked like Prateek's screenshots were taken when the viewport was smaller, hence the modals were too. Right now I'm using the default Bootstrap styles. I would recommend a wider modal if the viewport allows, as Bootstrap provides for us. Overriding the Bootstrap responsive design could be a bit involved, but Prateek might already have the CSS coded up.

• Prateek specified "OK" not "Close" for the buttons. I don't care which one is used but I assume we have a standard (do we?). If so, we should go with that.

I only had "Close" in my example since there was an existing message for it. This is shown in the "Attribution" modal (rightmost link in the footer). If we want OK, that's OK :) I can import this message from another application, but we might want to change the existing "Close" to "OK".

In T207776#4833168, @MusikAnimal wrote:

Sorry about that. I'm not sure what font sizes should be used, or the widths. To me it looked like Prateek's screenshots were taken when the viewport was smaller, hence the modals were too. Right now I'm using the default Bootstrap styles. I would recommend a wider modal if the viewport allows, as Bootstrap provides for us. Overriding the Bootstrap responsive design could be a bit involved, but Prateek might already have the CSS coded up.

Bootstrap lets you have smaller dialogs, just add modal-sm to the <div> that has the modal-dialog class. I am using the default Bootstrap fonts and sizes and I think you are too, I suppose they only look different because the modal size is different?

@MusikAnimal, could you make the modal smaller and share screenshots again?

I only had "Close" in my example since there was an existing message for it. This is shown in the "Attribution" modal (rightmost link in the footer). If we want OK, that's OK :) I can import this message from another application, but we might want to change the existing "Close" to "OK".

We can get rid of OK and stay with Close, its actually better now that I think of it.

In T207776#4836428, @Prtksxna wrote:

Bootstrap lets you have smaller dialogs, just add modal-sm to the <div> that has the modal-dialog class. I am using the default Bootstrap fonts and sizes and I think you are too, I suppose they only look different because the modal size is different?

Awesome! That makes it easy. I should mention I'm on Ubuntu now... so my screenshots will probably often look different. For instance Ubuntu Chromium doesn't seem to bolden header tags (e.g. <h1>), I added that rule manually. On that note, which heading are you using? Bootstrap examples use <h4>. Here's what I've got, using a boldened <h4> and .modal-sm:

It still looks different, probably just my system?

Full HTML, for reference:

<div class="modal fade in" id="progress_modal" tabindex="-1" role="dialog" aria-labelledby="progress_modal_label">
    <div class="modal-dialog modal-sm" role="document">
        <div class="modal-content">
            <div class="modal-header">
                <button type="button" class="close" data-dismiss="modal" aria-label="Close">
                    <span aria-hidden="true">×</span>
                </button>
                <h4 class="modal-title" id="progress_modal_label">
                    Data updating...
                </h4>
            </div>
            <div class="modal-body">
                <div class="spinner spinner--layout">
                    <div class="bounce"></div>
                </div>
                <p id="progress_modal_body">
                    This might take a while. The page will refresh automatically when update is complete.
                </p>
            </div>
        </div>
    </div>
</div>

That looks about right. I think the only difference left is to reduce the vertical margin of the loading indicator. On the prototype you can see the modal by going to the Event Page → Download Report → Wikidata Contributions. I think our markup is the same.

I've rewritten this so that it is just about the Timed Out message. Ignore everything about the "working" indicator, which is moved to a different ticket.

@MusikAnimal, this is rewritten now (again). It includes the generic message you wanted. I took out the Updating message. And Prateek removed the "OK" message from the design because it was unnecessary. Also I reworeded the messages based on your discussion. Sorry, but can you please go through the description again and make sure your messages match what is here. (This was part of the big UX refactoring I've been going through. Hopefully it will all stop moving now!).

@jmatazzoni Looks good! Though I will have to argue the correct venue for feedback (unrelated to strategic planning) would be https://meta.wikimedia.org/wiki/Talk:Event_Metrics. This is where we link to now in production.

@MusikAnimal do you want me to have this re-estimated? Or are you about done with it?

In T207776#4879211, @MusikAnimal wrote:

@jmatazzoni Looks good! Though I will have to argue the correct venue for feedback (unrelated to strategic planning) would be https://meta.wikimedia.org/wiki/Talk:Event_Metrics. This is where we link to now in production.

Ah, good idea. I've updated the Description.

do you want me to have this re-estimated? Or are you about done with it?

No need. I should have something to show later tonight or tomorrow.

PR ready for review: https://github.com/wikimedia/eventmetrics/pull/167

PR for fixing the emails: https://github.com/wikimedia/eventmetrics/pull/169

@MusikAnimal, I tested the dialog box and it seems to work fine except I noticed one thing: when I dismissed the the dialog (by clicking the X and by clicking outside the box, in my tests), the dialog box went away, but the page didn't reset itself fully to the Available state.

Instead, as you can see in the screenshot, it's in a kind of mixed-up state, where the Update button still says "Updating" instead of "Update data" and the "crunching the numbers..." message is still showing, but the Update button is not grayed out/available.

I guess this is my fault, for detailing the error messages themselves but not thinking to spec out the whole error-message sequence. So, for your convenience, the dismiss sequence should be:

• The dialog disappears.
• The On-Page Message shows the previous timestamp; I.e., it does not update.
• The Update button, Download menu and View Edit List button return to their available states.

I put that all in the Description, for posterity. Moving this back to In Development for you to have a look.

In T207776#4892927, @jmatazzoni wrote:

I tested the dialog box and it seems to work fine except I noticed one thing: when I dismissed the the dialog (by clicking the X and by clicking outside the box, in my tests), the dialog box went away, but the page didn't reset itself fully to the Available state.

It's supposed to go back to the fully available state, as you describe. I recall this not working for me either, until I cleared my browser's cache. Can you try that? Instructions at https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache#Bypassing_cache

I'm not sure what's going on. I've noticed sometimes other changes to the assets (JS/CSS) don't take effect until I clear my cache. This is what Webpack is supposed to do -- make sure only the newest assets are served. We will need to investigate. This is a separate issue, unrelated to this task.