Change 699003 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/Wikisource@master] [WIP] Show confirmation dialog if attempting OCR when the textbox isn't empty

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

I have a few questions:

• Rather than defining custom buttons that would look like the mock up image, I went with the default OOUI buttons (looks like "message dialog (generic)" from here). Customizing is easy, but it requires adding new i18n messages, and the resulting style would be different from what users might find in other places. Is it fine to keep the default style?
• I'm not sure I understand the second point. If there's an internal error, we currently notify the user via mw.notify, which displays a volatile message on the left. So, is the goal to replace this notification with a sticky error box below the page title? If this is the case, m2c: in MW, that kind of error display is normally used for failed POST requests (e.g. you try to save the page and the spam blacklist prevents that). Instead, given the client-side nature of the OCR process, if we are to replace the volatile notifications, would it make more sense to use an OOUI alert box? Something like "quick alert" from here. Additionally, would it make sense to create a separate task for this part?

• From a product perspective. definitely ok to keep the default button style.
• I'll default to @nayoub for the second question, but it seems to follow the same functionality minus the red urgency, which is a nice to have. But your proposed solution would be ok for meeting "functionality purposes"

Hi @Daimona! For the first point, I agree with @NRodriguez.
For the second point, the objective is to warn the user that they're about to perform a "destructive" task (e.g. replacing the text they have already edited with a new OCR transcription).
Although we are using "Message dialog (2 actions, long)" with a 'destructive' red OOUI button component, we can also use a "Quick Confirm" prompt if that's easier to develop.
Let me know if that makes sense :)

In T281767#7147289, @nayoub wrote:

For the second point, the objective is to warn the user that they're about to perform a "destructive" task (e.g. replacing the text they have already edited with a new OCR transcription).
Although we are using "Message dialog (2 actions, long)" with a 'destructive' red OOUI button component, we can also use a "Quick Confirm" prompt if that's easier to develop.
Let me know if that makes sense :)

Hi @nayoub! Thank you, and thanks @NRodriguez for your answers on the first point.

As for the second point, I'm sorry, I haven't been clear about the actual question. I was referring to the second outer bullet:

When the user encounters various errors, they will be an error state that is placed between the title field and toolbar, which states for all error types

so this is about generic error handling, not the "replace text" dialog. For visual reference, what we currently show is a bubble notification; also:

In T281767#7146182, @Daimona wrote:

which displays a volatile message on the left.

s/left/right/

Oh my bad @Daimona, I didn't get that.
The bubble notification works great for generic error handling. Thank you!

In T281767#7148421, @nayoub wrote:

Oh my bad @Daimona, I didn't get that.
The bubble notification works great for generic error handling. Thank you!

Perfect, thank you, and sorry again. @NRodriguez could you please confirm this from a product perspective? At that point, the patch on gerrit would be ready for review.

Change 699003 merged by jenkins-bot:

[mediawiki/extensions/Wikisource@master] Show confirmation dialog if attempting OCR when the textbox isn't empty

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

• When the user encounters the warning message for already having text in field of page body text and started editing, and if they want to run OCR:
  • There should be a pop-up that tells them in 2 lines:
    • "Replace with new text transcription?" (bigger text)
    • "You will lose the current page body text and it will be replaced with the newly transcribed text."

• There should be 2 buttons for:
  • continue
  • cancel

We have "Cancel" and "OK", not in red.

• When the user encounters various errors, they will be an error state that is placed between the title field and toolbar, which states for all error types:
  • "There has been an error. Please try a different text extraction tool (OCR engine)."

Message says: No text was returned by the OCR tool.

(It is hard to provoke this, but one way to do this is trying to transcribe one of the pages here, particularly if you choose the Google engine.)

• Note: This ticket does not include work to distinguish between different error types, such as timeout errors vs. formatting or other errors. We will just implement a general message that can apply to most cases and, if we want to further fine-tune the messaging, that can be tackled in a separate ticket.

So far, the error message/behaviour always appears the same. I have tested a few different types of errors including:

• Invalid language, image URL or tesseract options (which returns 200 but with an error message)
• Google service returns an error (400)
• Timeout or invalid OCR engine (500)

If the OCR tool's response is an error, the browser will reject the response because the HTTP header access-control-allow-origin is not set. For security reasons, the browser will reject it. We might need to fix this first if we want more fine-tuned messaging.

Test environment: https://en.wikisource.beta.wmflabs.org Wikisource – (cb4c670) 06:21, 18 June 2021.

All functionality confirmed from a product perspective! Also "Continue" versus "Ok" are interchangeable in this instance in my opinion, so I am "continue" with this change aka : P
That being said...
The error popover looks more like a message than an error, and because it disappears it can be a bit confusing for the user to know what went on.
I also think its a bit confusing that when you re-run the engine and it returns no text, your old text does not get replaced when there's an error. I think it's good that we are being cautious and not deleting their work if there was no text return, but it does make it counterintuitive that they press "ok proceeding" and nothing happens. I imagine this is an edge case, so it should not block the ticket from getting "Resolved" but something I want to point out for my own sanity.

Also, still seeing Extract Text in the button-- any chance we change that to Transcribe? Let me know if there's another ticket to add that to, not this one.

Thanks!

Your documentation and screenshots were really helpful @dom_walden (as always)

In T281767#7171377, @NRodriguez wrote:

The error popover looks more like a message than an error, and because it disappears it can be a bit confusing for the user to know what went on.

I think it should be trivial to make it a popup. What about "quick alert"?

I also think its a bit confusing that when you re-run the engine and it returns no text, your old text does not get replaced when there's an error. I think it's good that we are being cautious and not deleting their work if there was no text return, but it does make it counterintuitive that they press "ok proceeding" and nothing happens.

The "no text returned" thing is actually a generic error message, not e.g. "no text was returned because the image has no text", so I don't think we should empty the textbox. That said, would it be clearer if we switch the error message to a popup?

Also, still seeing Extract Text in the button-- any chance we change that to Transcribe? Let me know if there's another ticket to add that to, not this one.

I couldn't find any ticket about it. Should I create one?

Quick alert may be more disruptive than we want it to be, so let's just keep it as is. Disregard my comment on that.

Also, still seeing Extract Text in the button-- any chance we change that to Transcribe? Let me know if there's another ticket to add that to, not this one.

This can all be incorporated in Nicolas's design desk check ticket

Will resolve this one then!