UX: NVDA+F3, NVDA+Shift+F3, Find Error #7422
Comments
|
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 <notifications@github.com>
Sent: Thursday, January 10, 2019 1:45 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
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 <#7422 (comment)> , 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. |
|
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. |
|
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. |
|
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. |
|
I creaded #16451. |
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.
The text was updated successfully, but these errors were encountered: