nvaccess
UX: NVDA+F3, NVDA+Shift+F3, Find Error
When in browse mode and you hit something like q, and there is no next block quote, we get a spoken error but no alert box.
But when we do NVDA+F3 to search for text, and the text isn't found, we get an alert box with a "find error" in it. This requires the additional keystroke of hitting escape to clear this dialog.
Could the "find error" be spoken just as is the "no next block quote" message; i.e. with no alert box shown?
I know... it is just a single escape keystroke to clear the "find error" dialog, but often I will do NVDA+F3 successively on a bunch of PDF pages to find what I want. The escape keypress and Windows alert sound each time could be avoided if we changed to not use an alert.
I also wonder whether this is a user interface consistency issue, or if a "not found" (q) is different from an "error". I also wonder whether it's really a "find error". If it is a "find error" then it should be a "block quote error", which doesn't make much sense.
While it's true that these bringing up dialogs is inconsistent with single letter navigation, NVDA+f3 and NVDA+shift+f3 are arguably more closely related to NVDA+control+f, which brings up a dialog. In fact, the two f3 variants will bring up the Find dialog if a search string hasn't already been entered. If we did change this, that would make things inconsistent in relation to the Find dialog, since we bring up a dialog to enter the search string but then display the error without bringing up a dialog. In contrast, single letter navigation never brings up any dialogs.
Having said that, this would provide a simple solution to the second part of #7415 (supporting find commands for content recognition).
@QChristensen, @MichaelDCurran, thoughts?
My opinion is going to the option of NVDA+F3 and NVDA+Shift+F3 do not show a error dialog...
Rui
-----Mensagem Original----- De: James Teh Data: 19 de julho de 2017 22:47 Para: nvaccess/nvda Cc: Subscribed Assunto: Re: [nvaccess/nvda] UX: NVDA+F3, NVDA+Shift+F3, Find Error (#7422)
While it's true that these bringing up dialogs is inconsistent with single letter navigation, NVDA+f3 and NVDA+shift+f3 are arguably more closely related to NVDA+control+f, which brings up a dialog. In fact, the two f3 variants will bring up the Find dialog if a search string hasn't already been entered. If we did change this, that would make things inconsistent in relation to the Find dialog, since we bring up a dialog to enter the search string but then display the error without bringing up a dialog. In contrast, single letter navigation never brings up any dialogs.
Having said that, this would provide a simple solution to the second part of #7415 (supporting find commands for content recognition).
@QChristensen, @MichaelDCurran, thoughts?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Thanks! I agree in that we're trading one inconsistency for another. That said, there's no way we can do NVDA+ctrl+F without a dialog box. So the rule, consistently applied, could be: don't use a dialog/alert unless required. With that rule, NVDA+F3 could be consistent in not bringing up an alert when not found.
I don't quite think that this fixes 7415. You still couldn't use NVDA+CTRL+F to find something new. You could use NVDA+F3 to search for the next occurrence of the last find, though, and a "find error" wouldn't ruin it.
That's why I said it fixes the second part of #7415. :) The first part needs a separate fix, but I think I already know how to manage that.
Misread, sorry :( Cool, though! We could fix that and remove the (arguably) extraneous "find error" alert.
@michaelDCurran @feerrenrut Any thoughts on this? For me it seems to be a great addition, and if there are no objections I am going to implement this. The only thing which worries me a little are braille only users for whom the flash message maybe not enough to realize what has happened. @leonardder What is your opinion of this as a braille user?
@lukaszgo1
Łukasz, i don’t see a problem, as flash messages limit can be increased.
I am also an active Braille user
From: Łukasz Golonka [email protected] Sent: Thursday, January 10, 2019 1:45 PM To: nvaccess/nvda [email protected] Cc: Subscribed [email protected] Subject: Re: [nvaccess/nvda] UX: NVDA+F3, NVDA+Shift+F3, Find Error (#7422)
@michaelDCurran https://github.com/michaelDCurran @feerrenrut https://github.com/feerrenrut Any thoughts on this? For me it seems to be a great addition, and if there are no objections I am going to implement this. The only thing which worries me a little are braille only users for whom the flash message maybe not enough to realize what has happened. @leonardder https://github.com/leonardder What is your opinion of this as a braille user?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7422#issuecomment-453083608 , or mute the thread https://github.com/notifications/unsubscribe-auth/AKohk_7puh02eCXagY38RMkwHzTdMXAeks5vBzW7gaJpZM4OdVDZ . https://github.com/notifications/beacon/AKohk_kzzIPKJhJkDsm0mV815IEyesVcks5vBzW7gaJpZM4OdVDZ.gif
Limit definitely can be increased, however we have to ensure, that everything works nicely with the default config.
@lukaszgo1 are you still intending to raise a Pull request for this issue?
I've implemented it, worked with my implementation for a few hours. and I am no longer convinced that it is a good solution. The main problem is with the fact that before message about text not found the part of the document title is spoken. It works the same when the text is found, but now when the dialog pops-up the error sound is a good indication that we should dismiss it and search again, so there is no speed benefit in my view.
Actually, I was thinking about an alternative Approach. Instead of giving a warning by speech, there could be a very specific Sound indicating that no results have been found. A specific Sound like spelling error but for "no results found". In fact the Dialog would be obsolete because the only Action possible is to press "ok". But if #4637 will be implemented, the Dialog is needed anyway for the additional Action to search again from top. In conclusion, I think having this Dialog makes sense because Features can be added to it in the future. Thus, I am closing this as won't fix. If anyone has other arguments, please comment on it and we can reopen the discussion.
If #4637 would be implemented by @marlon-sousa the wrapping would be configurable, therefore some announcement about text not found would be still needed. I believe we should leave this open until #4637 is implemented and then com back to it. Alternatively if someone could provide appropriate sound I can open a PR with @Adriani90 idea.
Reopening and adding blocked Label since the implementation depends on #4637.
One major issue with the current dialog approach is that the location of the virtual cursor is lost in complex documents such as large pdf documents when they are opened in a browser. I think it would be more convenient to have a notification like "no further results" instead of the dialog. In case of large pdfs, NVDA has to find the previously focused text in the browse mode document after dismissing the dialog or pressing ok. In some large pdf documents NVDA freezes for more than 30 seconds until you can navigate in browse mode again.
If there are cases where NVDA takes a long time to restore its position in browse mode, that should be filed as a separate issue if it isn't already. That shouldn't really happen unless the document is doing something very strange like re-rendering the entire document. Also, that would have impacts far beyond the NVDA+f3 command. It would impact switching applications, opening any other dialog (even the browse mode find dialog itself), etc. Thus, that is somewhat separate from the request described here.