Topics

Developer toolkit gestures

Andy B.
 

Hi,

Someone brought it to my attention that Developer toolkit's gestures might have a slight problem. Currently, specific actions such as getting height, width, top, left, right, and bottom sizes/positions use letter keys on the keyboard, taking away the ability to implement familiar quicknav gestures later on. I could use the numpad for some of these, but then that requires laptop/desktop modes. Developer toolkit could make use of the F1-F12 keys in shifted, controlled, and alternative modes, but that adds extra complexity to something so simple. I am asking users for feedback on this issue.


James Scholes
 

I don't understand this part of your message:

taking away the ability to implement familiar quicknav gestures later on.
What does this mean? Why would your add-on need to reimplement any quick nav gestures? As that seems to be the entire impetus behind asking for feedback, it would be good to clarify what you mean.

Regards,

James Scholes

On 08/11/2019 at 2:00 pm, Andy B. wrote:
Hi,
Someone brought it to my attention that Developer toolkit's gestures might have a slight problem. Currently, specific actions such as getting height, width, top, left, right, and bottom sizes/positions use letter keys on the keyboard, taking away the ability to implement familiar quicknav gestures later on. I could use the numpad for some of these, but then that requires laptop/desktop modes. Developer toolkit could make use of the F1-F12 keys in shifted, controlled, and alternative modes, but that adds extra complexity to something so simple. I am asking users for feedback on this issue.

Andy B.
 

Hi,

On the web, NVDA has quicknav features such as h and shift+h for next/previous headings, t and shift+t for next/previous tables, b and shift+b for next/previous button, r and shift+r for next/previous radio button, and so on. Developer toolkit uses these gestures: h for height, w for width, t for top position, r for right position, l for left position, b for bottom position, shift+r for distance between object's right edge and its parent's right edge, shift+b for the distance between the object's bottom edge and the parent's bottom edge, c for child count, s for sibling count, p to announce the name of the object's relative parent, and more.
Someone recently brought it to my attention that Developer toolkit should allow the user to jump between web elements, similar to quicknav on the web. However, the add-on already uses a significant amount of the quicknav keys people are already familiar with. I could allow the user the ability to use the already assigned quicknav features provided by NVDA itself, but Developer toolkit reports objects in a different format than NVDA core does. An example from NVDA core: pressing h takes you to the next heading and reads heading + heading level + text. An example in Developer toolkit: pressing h would take you to the next heading and read title or text if there is no title + element type (section for example). Thus, a sample readout might be "test (section)". There are thoughts about using numpad to obtain things like left, top, right, bottom, height, width, and so on. However, laptop users without a numpad would end up in the original problem of using letter keys to obtain information. Other thoughts included using F1-F12, but there isn't enough of them to provide the required information. I am asking users to provide feedback on this particular problem. Is obtaining information more important than quicknav features? Should there be a balance? If so, what does it look like?

On Fri, Nov 8, 2019 at 9:31 AM James Scholes <james@...> wrote:
I don't understand this part of your message:

 > taking away the ability to implement familiar quicknav gestures later on.

What does this mean?  Why would your add-on need to reimplement any
quick nav gestures?  As that seems to be the entire impetus behind
asking for feedback, it would be good to clarify what you mean.

Regards,

James Scholes

On 08/11/2019 at 2:00 pm, Andy B. wrote:
> Hi,
>
> Someone brought it to my attention that Developer toolkit's gestures
> might have a slight problem. Currently, specific actions such as getting
> height, width, top, left, right, and bottom sizes/positions use letter
> keys on the keyboard, taking away the ability to implement familiar
> quicknav gestures later on. I could use the numpad for some of these,
> but then that requires laptop/desktop modes. Developer toolkit could
> make use of the F1-F12 keys in shifted, controlled, and alternative
> modes, but that adds extra complexity to something so simple. I am
> asking users for feedback on this issue.
>
>
>



James Scholes
 

Okay, I understand now. Personally I think a problem is being invented which doesn't need a solution. If a user wants to use quick nav, they should just turn off your add-on (a single keystroke), use quick nav to jump to the next element, and then turn the add-on back on. Does this cause a significant amount of inconvenience?

Regards,

James Scholes

On 08/11/2019 at 5:17 pm, Andy B. wrote:
Hi,
On the web, NVDA has quicknav features such as h and shift+h for next/previous headings, t and shift+t for next/previous tables, b and shift+b for next/previous button, r and shift+r for next/previous radio button, and so on. Developer toolkit uses these gestures: h for height, w for width, t for top position, r for right position, l for left position, b for bottom position, shift+r for distance between object's right edge and its parent's right edge, shift+b for the distance between the object's bottom edge and the parent's bottom edge, c for child count, s for sibling count, p to announce the name of the object's relative parent, and more.
Someone recently brought it to my attention that Developer toolkit should allow the user to jump between web elements, similar to quicknav on the web. However, the add-on already uses a significant amount of the quicknav keys people are already familiar with. I could allow the user the ability to use the already assigned quicknav features provided by NVDA itself, but Developer toolkit reports objects in a different format than NVDA core does. An example from NVDA core: pressing h takes you to the next heading and reads heading + heading level + text. An example in Developer toolkit: pressing h would take you to the next heading and read title or text if there is no title + element type (section for example). Thus, a sample readout might be "test (section)". There are thoughts about using numpad to obtain things like left, top, right, bottom, height, width, and so on. However, laptop users without a numpad would end up in the original problem of using letter keys to obtain information. Other thoughts included using F1-F12, but there isn't enough of them to provide the required information. I am asking users to provide feedback on this particular problem. Is obtaining information more important than quicknav features? Should there be a balance? If so, what does it look like?
On Fri, Nov 8, 2019 at 9:31 AM James Scholes <james@... <mailto:james@...>> wrote:
I don't understand this part of your message:
 > taking away the ability to implement familiar quicknav gestures
later on.
What does this mean?  Why would your add-on need to reimplement any
quick nav gestures?  As that seems to be the entire impetus behind
asking for feedback, it would be good to clarify what you mean.
Regards,
James Scholes
On 08/11/2019 at 2:00 pm, Andy B. wrote:
> Hi,
>
> Someone brought it to my attention that Developer toolkit's gestures
> might have a slight problem. Currently, specific actions such as
getting
> height, width, top, left, right, and bottom sizes/positions use
letter
> keys on the keyboard, taking away the ability to implement familiar
> quicknav gestures later on. I could use the numpad for some of
these,
> but then that requires laptop/desktop modes. Developer toolkit could
> make use of the F1-F12 keys in shifted, controlled, and alternative
> modes, but that adds extra complexity to something so simple. I am
> asking users for feedback on this issue.
>
>
>

Robert Hänggi
 

Maybe you could overload the NVDA+Shift+Space combo (single key
navigation) with your development mode.

On 08/11/2019, James Scholes <james@...> wrote:
Okay, I understand now. Personally I think a problem is being invented
which doesn't need a solution. If a user wants to use quick nav, they
should just turn off your add-on (a single keystroke), use quick nav to
jump to the next element, and then turn the add-on back on. Does this
cause a significant amount of inconvenience?

Regards,

James Scholes

On 08/11/2019 at 5:17 pm, Andy B. wrote:
Hi,

On the web, NVDA has quicknav features such as h and shift+h for
next/previous headings, t and shift+t for next/previous tables, b and
shift+b for next/previous button, r and shift+r for next/previous radio
button, and so on. Developer toolkit uses these gestures: h for height,
w for width, t for top position, r for right position, l for left
position, b for bottom position, shift+r for distance between object's
right edge and its parent's right edge, shift+b for the distance between
the object's bottom edge and the parent's bottom edge, c for child
count, s for sibling count, p to announce the name of the object's
relative parent, and more.
Someone recently brought it to my attention that Developer toolkit
should allow the user to jump between web elements, similar to quicknav
on the web. However, the add-on already uses a significant amount of the
quicknav keys people are already familiar with. I could allow the user
the ability to use the already assigned quicknav features provided by
NVDA itself, but Developer toolkit reports objects in a different format
than NVDA core does. An example from NVDA core: pressing h takes you to
the next heading and reads heading + heading level + text. An example in
Developer toolkit: pressing h would take you to the next heading and
read title or text if there is no title + element type (section for
example). Thus, a sample readout might be "test (section)". There are
thoughts about using numpad to obtain things like left, top, right,
bottom, height, width, and so on. However, laptop users without a numpad
would end up in the original problem of using letter keys to obtain
information. Other thoughts included using F1-F12, but there isn't
enough of them to provide the required information. I am asking users to
provide feedback on this particular problem. Is obtaining information
more important than quicknav features? Should there be a balance? If so,
what does it look like?

On Fri, Nov 8, 2019 at 9:31 AM James Scholes <james@...
<mailto:james@...>> wrote:

I don't understand this part of your message:

 > taking away the ability to implement familiar quicknav gestures
later on.

What does this mean?  Why would your add-on need to reimplement any
quick nav gestures?  As that seems to be the entire impetus behind
asking for feedback, it would be good to clarify what you mean.

Regards,

James Scholes

On 08/11/2019 at 2:00 pm, Andy B. wrote:
> Hi,
>
> Someone brought it to my attention that Developer toolkit's
gestures
> might have a slight problem. Currently, specific actions such as
getting
> height, width, top, left, right, and bottom sizes/positions use
letter
> keys on the keyboard, taking away the ability to implement
familiar
> quicknav gestures later on. I could use the numpad for some of
these,
> but then that requires laptop/desktop modes. Developer toolkit
could
> make use of the F1-F12 keys in shifted, controlled, and
alternative
> modes, but that adds extra complexity to something so simple. I am
> asking users for feedback on this issue.
>
>
>





derek riemer
 

You could just build a quicknav mode, and present the information in categories. I.E. arrow to the correct category arrow to it and select.

On Fri, Nov 8, 2019 at 10:23 PM Robert Hänggi <aarjay.robert@...> wrote:
Maybe you could overload the NVDA+Shift+Space combo (single key
navigation) with your development mode.

On 08/11/2019, James Scholes <james@...> wrote:
> Okay, I understand now.  Personally I think a problem is being invented
> which doesn't need a solution.  If a user wants to use quick nav, they
> should just turn off your add-on (a single keystroke), use quick nav to
> jump to the next element, and then turn the add-on back on.  Does this
> cause a significant amount of inconvenience?
>
> Regards,
>
> James Scholes
>
> On 08/11/2019 at 5:17 pm, Andy B. wrote:
>> Hi,
>>
>> On the web, NVDA has quicknav features such as h and shift+h for
>> next/previous headings, t and shift+t for next/previous tables, b and
>> shift+b for next/previous button, r and shift+r for next/previous radio
>> button, and so on. Developer toolkit uses these gestures: h for height,
>> w for width, t for top position, r for right position, l for left
>> position, b for bottom position, shift+r for distance between object's
>> right edge and its parent's right edge, shift+b for the distance between
>> the object's bottom edge and the parent's bottom edge, c for child
>> count, s for sibling count, p to announce the name of the object's
>> relative parent, and more.
>> Someone recently brought it to my attention that Developer toolkit
>> should allow the user to jump between web elements, similar to quicknav
>> on the web. However, the add-on already uses a significant amount of the
>> quicknav keys people are already familiar with. I could allow the user
>> the ability to use the already assigned quicknav features provided by
>> NVDA itself, but Developer toolkit reports objects in a different format
>> than NVDA core does. An example from NVDA core: pressing h takes you to
>> the next heading and reads heading + heading level + text. An example in
>> Developer toolkit: pressing h would take you to the next heading and
>> read title or text if there is no title + element type (section for
>> example). Thus, a sample readout might be "test (section)". There are
>> thoughts about using numpad to obtain things like left, top, right,
>> bottom, height, width, and so on. However, laptop users without a numpad
>> would end up in the original problem of using letter keys to obtain
>> information. Other thoughts included using F1-F12, but there isn't
>> enough of them to provide the required information. I am asking users to
>> provide feedback on this particular problem. Is obtaining information
>> more important than quicknav features? Should there be a balance? If so,
>> what does it look like?
>>
>> On Fri, Nov 8, 2019 at 9:31 AM James Scholes <james@...
>> <mailto:james@...>> wrote:
>>
>>     I don't understand this part of your message:
>>
>>       > taking away the ability to implement familiar quicknav gestures
>>     later on.
>>
>>     What does this mean?  Why would your add-on need to reimplement any
>>     quick nav gestures?  As that seems to be the entire impetus behind
>>     asking for feedback, it would be good to clarify what you mean.
>>
>>     Regards,
>>
>>     James Scholes
>>
>>     On 08/11/2019 at 2:00 pm, Andy B. wrote:
>>      > Hi,
>>      >
>>      > Someone brought it to my attention that Developer toolkit's
>> gestures
>>      > might have a slight problem. Currently, specific actions such as
>>     getting
>>      > height, width, top, left, right, and bottom sizes/positions use
>>     letter
>>      > keys on the keyboard, taking away the ability to implement
>> familiar
>>      > quicknav gestures later on. I could use the numpad for some of
>>     these,
>>      > but then that requires laptop/desktop modes. Developer toolkit
>> could
>>      > make use of the F1-F12 keys in shifted, controlled, and
>> alternative
>>      > modes, but that adds extra complexity to something so simple. I am
>>      > asking users for feedback on this issue.
>>      >
>>      >
>>      >
>>
>>
>>
>>
>
>
>
>





--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com