Start a new query when an existing one is running

Is this a bug report that it is possible to start a new query? Is this a feature request to be able to start a new query? Please edit the task summary - thanks.

Re: the open questions I think changing the run button to a stop button one second after to prevent a double click could be a simple and elegant solution to this.

And I think currently IPs can run multiple queries at once and the WMF already has safeguards in place to avoid exploitation of this.

Sharing an early version of the current design exploration. All feedback will be welcome and appreciated 🙏🏻

The current suggested solution consists in toggling the primary button in the Query Service to allow users to "run" and "stop" their queries. The flow would go as follows:

1. Immediately (100ms) after the “Run” button is pressed, it’s replaced by a “Stop” button.
2. If a user presses the “Stop” button while a query is running, the processing of the query stops and the button toggles back to "Run". The "stopping" of the query is also indicated by a message in the results area for clarity (I propose displaying the message for 200ms, even if the "stop" happens immediately).
3. Once the "Stop" button toggles back to "Run", the (new) query can be immediately ran again (going back to 1)
4. The "Stop" button displayed while the query is running automatically becomes "Run" again once the query results are ready/displayed.

Here's a gif showcasing the proposed manual toggling flow:

Please note that the "Stopping query" message displayed in the results area would be colored red (I used screenshots to save time).

Notes:

• Accidental double clicks are still a possibility in the suggested flow, but I think this is an acceptable trade-off inherent to all toggle buttons. Any ideas to prevent potential issues are welcome.
• As a runner-up, we considered re-enabling the "run" button when users modified the contents of a running query, but this option was discarded because it doesn't communicate explicitly that re-running the query is a possibility (one has to first make a change to realize). In the proposed flow, applying changes to the content of the query doesn't have any impact on the UI (toggling the button indirectly didn't sound like a good idea).

Open questions:

• We need to decide if the stop functionality needs a keyboard shortcut and which one that would be (users can currently press "ctrl+enter" to run queries. this is indicated by a tooltip when users hover the "Run" button)
• Would it be at all possible to use cdx-button in the Query Service?
• I'd suggest validating this solution before its release: we could deploy the changes in test.wikidata and publishing a structured call for feedback from the community.

Thanks so much for this Sarai, this all looks great to me.

I think a keyboard shortcut like the one you suggested ctrl+enter would make sense here.
To avoid a double click we could possibly have a delay between the run and stop button?

Re: testing, as we discussed in the last story writing we won't be able to do this on test wikidata but we can get some feedback through a prototype or even through the gif of the flow you created.

Call for feedback

Opening a more formal call for feedback in this comment, for anyone interested in helping us shape this solution 🙏🏻
We'll share a quick feedback survey with the extended Wikidata community soon, but the opinions of the people subscribed to this and related tickets are specially relevant for us.

Summary of the solution: Run/Stop query toggle button

Our current working solution to the problem documented in this task involves providing a "Stop" button in the Query Service. This button will immediately replace the “Run” button once the latter is pressed.

Using the “Stop” button while a query is running will interrupt the processing of the query in the interface. Pressing "Stop" will also make the button to toggle back to “Run”, enabling this behavior again for users.

Something to keep in mind is that the solution only makes the query stop at an interface level. Even if users will receive the indication that the query is "stopped", it will technically still be running on the server's side. We'll be just unlocking the possibility to run the query again on the Query Service interface.

Curious to try? Here's a very limited prototype that allows you to run and stop a query and try out this new behavior:

Disclaimer: Please note that typing or clicking any other elements on the page is not possible, due to the limitations of this very rough prototype. Styles and design are not final.

Questions

Here's a set of questions that we hope can guide you to provide feedback. We're particularly interested in your understanding of the solution, in whether you find it natural and easy to integrate in your current workflows:

1. Do you find any part of the Run/Stop toggle feature confusing or hard to understand?

2. Do you see the Run/Stop toggle as a helpful addition or a potential disruption to your experience with the Query Service?

3. Is there anything about the solution that could be problematic? Any risks we might be overlooking?

4. Is there anything we could do to make this solution more convenient for you?

Please let us know any other thoughts or suggestions you might have about this solution, its convenience or challenges. Any shape or form is valid and appreciated.

Thank you for your time!

Posting a progress update on the design exploration. Att @Arian_Bozorg and @Lydia_Pintscher

TL;DR: We need help validating whether the risk of overloading the WQS servers due to the implementation of the Run/Stop toggle solution is a serious one. We also need to agree on a strategy: should we preventively modify the design solution further (making it slightly less streamlined), or go ahead and act in case we notice a risky increase on the volume of queries?

In the last two weeks, we approached the Wikidata community to test the Run/Stop toggle button solution described above. We used a survey to collect feedback from volunteers on two main areas:

1. Their understanding of the solution: Here the data collected was overwhelmingly positive. The great majority of users interpreted the behavior exactly as intended, and didn't find anything about the proposal confusing.

2. Potential risks, concerns and improvements they would suggest in order to adjust the feature to their needs: When it comes to their concerns, there were some clear patterns. The most frequently mentioned issue was the risk of overloading the WQS server, due to the facilitation of running multiple heavy queries in parallel, accidental double clicks, and active vandalism (DDoS attacks). As potential solutions, users brought up strategies like avoiding making the "Stop query" functionality available for bots, or actually stopping the query on the server side (which I'm aware is not feasible). They also mentioned some redesign suggestions that we're integrating in the next iteration (whenever suitable), and made very interesting comments regarding the lack of visibility of the server's status (users don't get an estimation of the query execution time, nor know when it's struggling – I believe there's a very interesting improvement opportunity here).

Our first inclination to address the server overload concern was to come up with a different design alternative, one that provides a "rerun" option only when the query is modified. We are currently testing this new solution in a follow-up survey (distributed via different channels to avoid any spamming). Nevertheless, we are aware that this alternative is a less optimal solution in terms of discoverability and accessibility, so we are less confident it'll do better during the tests.

Now, the more technical question that we need help validating is: In general, an increase in the volume of queries can be expected as a result of these changes. But, how serious should we take this overload concern? Should we put strategies in place to prevent any overloads at this point (e.g. create a bit more friction at the design level), or can we wait to track performance and see if we need to correct our solution later?

Sharing a sneak peek of the state of the current design iteration.

There were three main adjustments applied to this new version:

1. The Run and Stop buttons are separated to prevent double clicks and improve accessibility (making all options detectable by default via screen reader).
2. The Stop/Cancel action is effectively immediate, instead of after a short delay to avoid unnecessary (even if short) waiting times
3. There's a permanent (until a new query is run) message in the results area indicating that the query was "cancelled" (instead of stopped). This sounded like a UX writing improvement based on user feedback (alternatively, "Abandoned" was suggested).

Disclaimer: Visual design (color, sizes) is not final.

In T245643#9495822, @Sarai-WMDE wrote:

2. Potential risks, concerns and improvements they would suggest in order to adjust the feature to their needs: When it comes to their concerns, there were some clear patterns. The most frequently mentioned issue was the risk of overloading the WQS server, due to the facilitation of running multiple heavy queries in parallel, accidental double clicks, and active vandalism (DDoS attacks). As potential solutions, users brought up strategies like avoiding making the "Stop query" functionality available for bots, or actually stopping the query on the server side (which I'm aware is not feasible). They also mentioned some redesign suggestions that we're integrating in the next iteration (whenever suitable), and made very interesting comments regarding the lack of visibility of the server's status (users don't get an estimation of the query execution time, nor know when it's struggling – I believe there's a very interesting improvement opportunity here).

We brought it up with @Gehel and @dcausse in a call a while ago and the result was that the existing mitigations on the serverside should prevent bad effects of this.

That's great news Sarai! With the risk of overloading the server mitigated as Lydia said in her comment, let's move ahead with the design.

I'll update the ticket accordingly

Open question: Can we use Codex buttons to replace the current "Run" button and add the new "Stop" option?

In T245643#9502079, @Sarai-WMDE wrote:

Open question: Can we use Codex buttons to replace the current "Run" button and add the new "Stop" option?

We can use the CSS-only version of Codex button component. I assume it would be enough, what do you think @Sarai-WMDE?

Story writing notes and decisions:

1. We'll use our reusable variables to create the spacing around and between the Execute and Stop buttons.

2. The QT team will need to investigate whether using Codex buttons (in either their Vue or CSS version) is an option in the Query Service. This information will influence this tasks' estimation during the next sprint planning. -> Done, see comment above

3. We evaluated the introduction of a "cancelling query" message indicator to communicate the transition from running to stopping the query: while we subjectively believe this is a good idea (the message was even included in the first version of the prototype), we don't really have proof of the benefits of introducing this extra step. On the contrary, we received feedback against adding this unnecessary waiting time. For now, I would suggest us moving forward without doing this, and only incorporate this progress indicator later, in case we detect it's necessary to limit how streamlined the workflow is at the moment (see next point).

4. For now, the decision has been to wait and track whether servers' performance is impacted by these upcoming changes to the QS UI, and add design mitigations in case overloads are detected (e.g. increase waiting times, add a Cancel confirmation dialog). Nevertheless, the WDQT team would like to know if there's anything that we can do from our side to prevent making this new Cancel functionality unavailable for bots: is this a strategy that sounds necessary to the Search Platform / Query Service Team? What can our team do to support that? Maybe @Lydia_Pintscher can help us validate/ clarify this? 🙏🏻

We can use the CSS-only version of Codex button component. I assume it would be enough, what do you think @Sarai-WMDE?

Sounds great. That's more than enough given the limitations. I'll add the finding to the task description. Thank you, Hasan! 💯

In T245643#9537162, @Sarai-WMDE wrote:

4. For now, the decision has been to wait and track whether servers' performance is impacted by these upcoming changes to the QS UI, and add design mitigations in case overloads are detected (e.g. increase waiting times, add a Cancel confirmation dialog). Nevertheless, the WDQT team would like to know if there's anything that we can do from our side to prevent making this new Cancel functionality unavailable for bots: is this a strategy that sounds necessary to the Search Platform / Query Service Team? What can our team do to support that? Maybe @Lydia_Pintscher can help us validate/ clarify this? 🙏🏻

We have discussed it and decided that it is not necessary at this point because the blocking does and should happen at the server level.

Change 1007423 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[wikidata/query/gui@master] [WiP] Stop current query from running on Query Service

https://gerrit.wikimedia.org/r/1007423

Change 1009481 had a related patch set uploaded (by Hasan Akgün (WMDE); author: Hasan Akgün (WMDE)):

[wikidata/query/gui@master] Cancel query ajax request

https://gerrit.wikimedia.org/r/1009481

Change 1007423 abandoned by Guergana Tzatchkova:

[wikidata/query/gui@master] [WiP] Stop current query from running on Query Service

Reason:

Abandoning this patch because issue has been solved in Change-Id: I8a02ea488214a4ef04457a781dd046d78866c2e7

https://gerrit.wikimedia.org/r/1007423

Change 1007423 restored by Hasan Akgün (WMDE):

[wikidata/query/gui@master] [WiP] Stop current query from running on Query Service

https://gerrit.wikimedia.org/r/1007423

Change 1007423 abandoned by Hasan Akgün (WMDE):

[wikidata/query/gui@master] [WiP] Stop current query from running on Query Service

Reason:

cont. on somewhere else

https://gerrit.wikimedia.org/r/1007423

Change 1009481 merged by jenkins-bot:

[wikidata/query/gui@master] Stop current query from running on Query Service

https://gerrit.wikimedia.org/r/1009481

There's a cached version of i18n file and it isn't updated yet (I don't know why), so you can see messages like wdqs-action-stop-query that. They will disappear in a short time. @Arian_Bozorg

Thanks Hasan, it's looking good :)

Just a couple of small changes here:

• can we adjust the copy so that it reads "The query was cancelled"
• the padding also looks a little off here too, it should be centred vertically as well as horizontally

cc: @Sarai-WMDE

Agreed, with the UI looking good and with the needed copy fix. I can't reproduce the message padding issues, though. Could it be related to font size or family?

I detected some further adjustments needed to follow the original specs. Please let me know if there's anything mentioned that's actually not feasible:

Change	Current	Specified
1. Fix vertical padding around and between the run and cancel buttons		All noted spacing should be 0.5rem. (Maybe we could use our custom spacing variables?)
2. The default size of large Codex buttons shouldn't be overridden		The buttons should display a size of 44x44px
3. Aria-labels are not accessible	When the Run and Cancel buttons are focused, VoiceOver reads the literal aria-labels content ("wdqs-app-button-run-aria-label" and "wdqs-app-button-cancel-aria-label") instead of the intended message	The correct message should be provided via these aria labels to users of assistive technology
4. Fix copy of Cancel button's title	title="Stop query (CTRL + ESC)"	The action should be "cancel" instead of "stop". The message would read: "Cancel query (CTRL+ESC)"
5. Make it possible to cancel queries using the "CTRL + ESC" keyboard shortcut	While a query is being executed, pressing the key combination "CTRL + ESC" has no effect	Pressing "CTRL + ESC" should have the same effect as pressing the Cancel button: the query should stop from running in the UI

The last point (5) wasn't actually made explicit in this ticket, so it'd be understandable if the team preferred to create a subtask to implement that.

Change 1013058 had a related patch set uploaded (by Hasan Akgün (WMDE); author: Hasan Akgün (WMDE)):

[wikidata/query/gui@master] Fix query cancellation bugs

https://gerrit.wikimedia.org/r/1013058

@Arian_Bozorg I've fixed the sentence, but when I checked the vertical alignment I saw it's the same with "Running query" message as well. I couldn't find a proper solution for it, so if it's OK for you I think we can handle that one in a separate task. Please let me know.

@Sarai-WMDE I've fixed all of your findings, in addition to them I've added help text for the cancel query shortcut to the keyboard shortcuts info modal. It'd be awesome if you check the attached screenshot and let me know if it works.

If I have a "go" sign from both of you, I will merge the code after the reviews so you can test everything on the production site like the last time.

Thanks Hasan, that's sounds good from me

Thanks, @HasanAkgun_WMDE! Wasn't aware of the existence of that modal 😯 Looking forward to taking a look at the changes 🙏🏻

I wasn't aware of that modal to list the keyboard shortcuts either. And the shortcut ? seems partially broken? It works when opening the query service UI freshly, but fails after running a query. I've created T360880: Shortcut Modal fails to open after running a query for that.

Thanks, @Michael! That's much appreciated 🙏🏻