New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

To have braille insure that lists and such consistently present the start of items in the same place on the display #217

Closed
nvaccessAuto opened this Issue Jan 1, 2010 · 11 comments

Comments

Projects
None yet
4 participants
@nvaccessAuto

nvaccessAuto commented Jan 1, 2010

Reported by valiant8086 on 2008-10-31 12:23
When you arrow through a list of items and are reading the braille display, the start of each list item may begin in a different place for one list item than it is for another. This makes it more difficult to easily arrow down through a list in search of something, because you have to stop and read the display to be able to find the list item. Right now, NVDA tries to make sure the end of the text in such a situation is displayed that is, the display will be presented with the right end of the text. Any text not on the display for that line will usually be to the left, in theory, and the user would reverse advance to read it. I want to try and switch things around a little to see if we can at least do something to where the beginnings of list items and things don't move left and right depending on how long the text is. For example, Maybe we could show li on the left end of the display to indicate this is a list item. After that there would be one space, then the text of that list item. If I were to arrow up and down through the list, that li at the left end would not move, and the text of the list item would consistently begin in the same place on the display. This may mean to do this that braille will need to either not show things like dialogue names, or show them only after the currently focused control. Having this functionality is very important to me. I really feel strongly that it will make doing things useing braille much much more reasonable. I have thought long about whether we would start missing out on information by doing this and I don't think so. If we can just re-arange where things are displayed, we should be ok. This functionality should appear in all possible situations, list items, folder view list views, tree views, combo boxes in and out of virtual buffers, menu items, start menu, etc. Heck i think it should do that for buttons and checkboxes and things too. the idea is present the control that currently has focus on the left end, and put the rest of the information on the right of that. if I want to read which dialogue i'm in etc, I can advance to take a look, assuming the display didn't have enough room to show that before hand.
Blocking #4659

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Jan 1, 2010

Comment 1 by jteh on 2008-10-31 13:26
Placing the focused item at the left hand side of the display means one of two things:

  • The context will not be shown. In this case, in a yes/no message prompt dialog, you will see only "Yes btn" and no message indicating what this refers to. This does not provide enough information for those relying either primarily or entirely on braille.
    • One possible solution is to have an option to always scroll the focus to the left of the display by default. This means that you won't see context, but you can scroll backwards to find it. I don't believe this should be the default, but it probably isn't hard to make this configurable. Thus, in the above example, you can see "Yes btn", but if you scroll back, you will see the dialog message and other context.
  • You proposed that the context could be shown after the focus. However, this is not logical.
    • IN the above example, the message would be shown after the prompt; e.g. "Yes btn Exit NVDA dlg Are you sure you want to exit NVDA?"
    • Even if this makes sense to you, consider more complex cases of context. Should we show the entire context backwards from bottom to top or just the context in the usual order after the focus?
    • What about documents? Currently, the document object and its context will appear if you scroll past the top of the document. With your proposal, the context will suddenly appear at the bottom of the document.

nvaccessAuto commented Jan 1, 2010

Comment 1 by jteh on 2008-10-31 13:26
Placing the focused item at the left hand side of the display means one of two things:

  • The context will not be shown. In this case, in a yes/no message prompt dialog, you will see only "Yes btn" and no message indicating what this refers to. This does not provide enough information for those relying either primarily or entirely on braille.
    • One possible solution is to have an option to always scroll the focus to the left of the display by default. This means that you won't see context, but you can scroll backwards to find it. I don't believe this should be the default, but it probably isn't hard to make this configurable. Thus, in the above example, you can see "Yes btn", but if you scroll back, you will see the dialog message and other context.
  • You proposed that the context could be shown after the focus. However, this is not logical.
    • IN the above example, the message would be shown after the prompt; e.g. "Yes btn Exit NVDA dlg Are you sure you want to exit NVDA?"
    • Even if this makes sense to you, consider more complex cases of context. Should we show the entire context backwards from bottom to top or just the context in the usual order after the focus?
    • What about documents? Currently, the document object and its context will appear if you scroll past the top of the document. With your proposal, the context will suddenly appear at the bottom of the document.
@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Jan 1, 2010

Comment 2 by valiant8086 (in reply to comment 1) on 2008-10-31 15:53
What does context mean in this case? Sorry. I wonder if you could go yes btn do you want to shut down NVDA? shutdown NVDA dlg. How does this apply to documents? I hadn't realized documents would be affected, since as far as I knew only the document's contents was shown. Although I guess if I reverse advance far enough I would find the title of the program that was displaying the document. What did you mean by showing the entire context from top to bottom? I'm assuming, more than likely correctly that this means to show

  • yes btn are you sure you want to shut down NVDA? exit NVDA dlg
    instead of
    *yes btn exit NVDA dlg are you sure you want to shut down NVDA?
    if I understood that correctly then yes this is what i'm after. Since although this isn't so for a beginning user, I know which dialogue i'm in, and can confirm that by reading the options and questions at hand. I just want quick and relyable access to the very control that I put focus on. If I want need to confirm where I am, I can read further on until I get the information i'm after. I'm not sure where this would get non-logical, to me anyway.

I'll try to think up some situations here

max battery li choose a power scheme tx power options dlg
that works good so far
my documents 1 of 3 flv desktop
where flv meant folder view list view. Unable to understand what you were saying about documents, at the moment. Although admittedly if I land in a multy-line edit field and want to know what it's for, I would have to advance a bunch to get to the end and figure out what the dialogue might be telling me to do with this multy-line-edit field, for instance for a license agreement. Ah, I bet that's basically what you meant. Hmm, good question what to do there. should situations like that work like they do right now instead of backwards?Hmm lack of consistancy. I suppose maybe we could hit NVDA+tab? I guess it does sound illogical but it's exactly what I'm looking for, I think. The idea is the item of most focus might be displayed right at hand, then after that the dialogue text followed by dialogue name for example. I would expect to be able to toggle this setting on and off since I suspect some would dislike it.

Replying to jteh:

Placing the focused item at the left hand side of the display means one of two things:

  • The context will not be shown. In this case, in a yes/no message prompt dialog, you will see only "Yes btn" and no message indicating what this refers to. This does not provide enough information for those relying either primarily or entirely on braille.
    • One possible solution is to have an option to always scroll the focus to the left of the display by default. This means that you won't see context, but you can scroll backwards to find it. I don't believe this should be the default, but it probably isn't hard to make this configurable. Thus, in the above example, you can see "Yes btn", but if you scroll back, you will see the dialog message and other context.
  • You proposed that the context could be shown after the focus. However, this is not logical.
    • IN the above example, the message would be shown after the prompt; e.g. "Yes btn Exit NVDA dlg Are you sure you want to exit NVDA?"
    • Even if this makes sense to you, consider more complex cases of context. Should we show the entire context backwards from bottom to top or just the context in the usual order after the focus?
    • What about documents? Currently, the document object and its context will appear if you scroll past the top of the document. With your proposal, the context will suddenly appear at the bottom of the document.

nvaccessAuto commented Jan 1, 2010

Comment 2 by valiant8086 (in reply to comment 1) on 2008-10-31 15:53
What does context mean in this case? Sorry. I wonder if you could go yes btn do you want to shut down NVDA? shutdown NVDA dlg. How does this apply to documents? I hadn't realized documents would be affected, since as far as I knew only the document's contents was shown. Although I guess if I reverse advance far enough I would find the title of the program that was displaying the document. What did you mean by showing the entire context from top to bottom? I'm assuming, more than likely correctly that this means to show

  • yes btn are you sure you want to shut down NVDA? exit NVDA dlg
    instead of
    *yes btn exit NVDA dlg are you sure you want to shut down NVDA?
    if I understood that correctly then yes this is what i'm after. Since although this isn't so for a beginning user, I know which dialogue i'm in, and can confirm that by reading the options and questions at hand. I just want quick and relyable access to the very control that I put focus on. If I want need to confirm where I am, I can read further on until I get the information i'm after. I'm not sure where this would get non-logical, to me anyway.

I'll try to think up some situations here

max battery li choose a power scheme tx power options dlg
that works good so far
my documents 1 of 3 flv desktop
where flv meant folder view list view. Unable to understand what you were saying about documents, at the moment. Although admittedly if I land in a multy-line edit field and want to know what it's for, I would have to advance a bunch to get to the end and figure out what the dialogue might be telling me to do with this multy-line-edit field, for instance for a license agreement. Ah, I bet that's basically what you meant. Hmm, good question what to do there. should situations like that work like they do right now instead of backwards?Hmm lack of consistancy. I suppose maybe we could hit NVDA+tab? I guess it does sound illogical but it's exactly what I'm looking for, I think. The idea is the item of most focus might be displayed right at hand, then after that the dialogue text followed by dialogue name for example. I would expect to be able to toggle this setting on and off since I suspect some would dislike it.

Replying to jteh:

Placing the focused item at the left hand side of the display means one of two things:

  • The context will not be shown. In this case, in a yes/no message prompt dialog, you will see only "Yes btn" and no message indicating what this refers to. This does not provide enough information for those relying either primarily or entirely on braille.
    • One possible solution is to have an option to always scroll the focus to the left of the display by default. This means that you won't see context, but you can scroll backwards to find it. I don't believe this should be the default, but it probably isn't hard to make this configurable. Thus, in the above example, you can see "Yes btn", but if you scroll back, you will see the dialog message and other context.
  • You proposed that the context could be shown after the focus. However, this is not logical.
    • IN the above example, the message would be shown after the prompt; e.g. "Yes btn Exit NVDA dlg Are you sure you want to exit NVDA?"
    • Even if this makes sense to you, consider more complex cases of context. Should we show the entire context backwards from bottom to top or just the context in the usual order after the focus?
    • What about documents? Currently, the document object and its context will appear if you scroll past the top of the document. With your proposal, the context will suddenly appear at the bottom of the document.
@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh May 25, 2017

Contributor

CC @leonardder, @dkager.

I'd appreciate your thoughts on #217 (comment).

There's also another option: determine what to focus at the left of the display based on new focus ancestry, just as we do for speech. For example, if you open a simple dialog, you might see "Prompt dlg Yes btn", but if you press tab, "No btn" would be all you see; you'd have to scroll back to see the dialog. This means you do know that context has changed when it's significant, but you wouldn't have to deal with items constantly moving about in a menu, for example.

Contributor

jcsteh commented May 25, 2017

CC @leonardder, @dkager.

I'd appreciate your thoughts on #217 (comment).

There's also another option: determine what to focus at the left of the display based on new focus ancestry, just as we do for speech. For example, if you open a simple dialog, you might see "Prompt dlg Yes btn", but if you press tab, "No btn" would be all you see; you'd have to scroll back to see the dialog. This means you do know that context has changed when it's significant, but you wouldn't have to deal with items constantly moving about in a menu, for example.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 25, 2017

Collaborator

I probably missed this issue since it is so old, so sorry for the duplicate. Anyway

  • One possible solution is to have an option to always scroll the focus to the left of the display by default. This means that you won't see context, but you can scroll backwards to find it. I don't believe this should be the default, but it probably isn't hard to make this configurable. Thus, in the above example, you can see "Yes btn", but if you scroll back, you will see the dialog message and other context.

I agree with this and would be happy to find out how this can be realised.

  • You proposed that the context could be shown after the focus. However, this is not logical.

I agree, but the proposed behaviour isn't strange. It is actually the default behaviour in JAWS. It shows everything in reversed order, so first you see the button, followed by the message and the dialog title. It has its charms, but not more than that, and I don't think we should consider this at this point.

@dkager, any thoughts about this?

Collaborator

leonardder commented May 25, 2017

I probably missed this issue since it is so old, so sorry for the duplicate. Anyway

  • One possible solution is to have an option to always scroll the focus to the left of the display by default. This means that you won't see context, but you can scroll backwards to find it. I don't believe this should be the default, but it probably isn't hard to make this configurable. Thus, in the above example, you can see "Yes btn", but if you scroll back, you will see the dialog message and other context.

I agree with this and would be happy to find out how this can be realised.

  • You proposed that the context could be shown after the focus. However, this is not logical.

I agree, but the proposed behaviour isn't strange. It is actually the default behaviour in JAWS. It shows everything in reversed order, so first you see the button, followed by the message and the dialog title. It has its charms, but not more than that, and I don't think we should consider this at this point.

@dkager, any thoughts about this?

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 25, 2017

Collaborator

There's also another option: determine what to focus at the left of the display based on new focus ancestry, just as we do for speech. For example, if you open a simple dialog, you might see "Prompt dlg Yes btn", but if you press tab, "No btn" would be all you see; you'd have to scroll back to see the dialog.

Hmm, I really like this one. It is kind of an intermediate between always showing the ancestry and always having to scroll back to see it. So either I'd go for this one and the current behaviour, or allow the users to choose between the three different behaviours.

Collaborator

leonardder commented May 25, 2017

There's also another option: determine what to focus at the left of the display based on new focus ancestry, just as we do for speech. For example, if you open a simple dialog, you might see "Prompt dlg Yes btn", but if you press tab, "No btn" would be all you see; you'd have to scroll back to see the dialog.

Hmm, I really like this one. It is kind of an intermediate between always showing the ancestry and always having to scroll back to see it. So either I'd go for this one and the current behaviour, or allow the users to choose between the three different behaviours.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager May 25, 2017

Collaborator

So I like seeing context and I also like my focus text to start in the same, predictable place. Based on this, I have one more insane option. I suppose it's like status cells.
We could allow a user to set a point on their braille display at which the focus object starts. If you set this in the middle of a 40-cell display, then the left 20 cells would contain the end of the context and the right 20 cells would contain the start of the focus. You can then scroll either way if you need more information. It could work on an 80-cell display, but I hate to think what would come out on a 14-cell one.

Collaborator

dkager commented May 25, 2017

So I like seeing context and I also like my focus text to start in the same, predictable place. Based on this, I have one more insane option. I suppose it's like status cells.
We could allow a user to set a point on their braille display at which the focus object starts. If you set this in the middle of a 40-cell display, then the left 20 cells would contain the end of the context and the right 20 cells would contain the start of the focus. You can then scroll either way if you need more information. It could work on an 80-cell display, but I hate to think what would come out on a 14-cell one.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager May 25, 2017

Collaborator

I also like the intelligent approach of placing focus hard left if the ancestry hasn't changed. This requires more training time for it to become intuitive, but after that it is probably the most efficient (and novel, which doesn't hurt).

Collaborator

dkager commented May 25, 2017

I also like the intelligent approach of placing focus hard left if the ancestry hasn't changed. This requires more training time for it to become intuitive, but after that it is probably the most efficient (and novel, which doesn't hurt).

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh May 25, 2017

Contributor

@leonardder commented on [May 25, 2017, 4:59 PM GMT+10]

Hmm, I really like this one. It is kind of an intermediate between always showing the ancestry and always having to scroll back to see it.

I assume you'd still want it to show as much of the focused control as possible as we do now? For example, if a dialog appeared and focused a button and both were too long to fit on the display, you'd still expect to have to scroll back to see the full dialog text?

Contributor

jcsteh commented May 25, 2017

@leonardder commented on [May 25, 2017, 4:59 PM GMT+10]

Hmm, I really like this one. It is kind of an intermediate between always showing the ancestry and always having to scroll back to see it.

I assume you'd still want it to show as much of the focused control as possible as we do now? For example, if a dialog appeared and focused a button and both were too long to fit on the display, you'd still expect to have to scroll back to see the full dialog text?

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh May 25, 2017

Contributor

@leonardder commented on May 25, 2017, 4:55 PM GMT+10:

  • One possible solution is to have an option to always scroll the focus to the left of the display by default.

I agree with this and would be happy to find out how this can be realised.

I think this should be fairly simple. In BrailleBuffer.focus, you'll see that we return early if region.focusToHardLeft is True. You simply also return True there if this new config setting is True.

In contrast, now that I've grabbed your interest with this other idea of scrolling based on ancestry changes, I'm not sure how that would be implemented. :( _set_windowEndPos would have to be tweaked somehow so that the minimum position it will allow (restrictPos variable) is the region for the first new focus ancestor. But how to get that region from there? I guess we could introduce a new attribute on regions which is set by getFocusContextRegions, but even then, _set_windowEndPos still has to walk back through the regions... and regions don't link to each other right now.

Contributor

jcsteh commented May 25, 2017

@leonardder commented on May 25, 2017, 4:55 PM GMT+10:

  • One possible solution is to have an option to always scroll the focus to the left of the display by default.

I agree with this and would be happy to find out how this can be realised.

I think this should be fairly simple. In BrailleBuffer.focus, you'll see that we return early if region.focusToHardLeft is True. You simply also return True there if this new config setting is True.

In contrast, now that I've grabbed your interest with this other idea of scrolling based on ancestry changes, I'm not sure how that would be implemented. :( _set_windowEndPos would have to be tweaked somehow so that the minimum position it will allow (restrictPos variable) is the region for the first new focus ancestor. But how to get that region from there? I guess we could introduce a new attribute on regions which is set by getFocusContextRegions, but even then, _set_windowEndPos still has to walk back through the regions... and regions don't link to each other right now.

@jcsteh jcsteh removed their assignment May 26, 2017

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder May 27, 2017

Collaborator

@dkager commented:

Based on this, I have one more insane option. I suppose it's like status cells. We could allow a user to set a point on their braille display at which the focus object starts. If you set this in the middle of a 40-cell display, then the left 20 cells would contain the end of the context and the right 20 cells would contain the start of the focus. You can then scroll either way if you need more information.

Honestly, I wouldn't use such functionality since it will probably always force me to scroll somehow. Would you prefer this one over the three other approaches mentioned here, the current approach, focus to hard left and the hybrid of these?

@jcsteh commented:

I assume you'd still want it to show as much of the focused control as possible as we do now? For example, if a dialog appeared and focused a button and both were too long to fit on the display, you'd still expect to have to scroll back to see the full dialog text?

This is correct indeed.

Collaborator

leonardder commented May 27, 2017

@dkager commented:

Based on this, I have one more insane option. I suppose it's like status cells. We could allow a user to set a point on their braille display at which the focus object starts. If you set this in the middle of a 40-cell display, then the left 20 cells would contain the end of the context and the right 20 cells would contain the start of the focus. You can then scroll either way if you need more information.

Honestly, I wouldn't use such functionality since it will probably always force me to scroll somehow. Would you prefer this one over the three other approaches mentioned here, the current approach, focus to hard left and the hybrid of these?

@jcsteh commented:

I assume you'd still want it to show as much of the focused control as possible as we do now? For example, if a dialog appeared and focused a button and both were too long to fit on the display, you'd still expect to have to scroll back to see the full dialog text?

This is correct indeed.

@dkager

This comment has been minimized.

Show comment
Hide comment
@dkager

dkager May 31, 2017

Collaborator

Honestly, I wouldn't use such functionality since it will probably always force me to scroll somehow.

There is a parallel here. Do you always listen to everything speech has to say? That was my motivationfor suggesting the midway point. In a GUI that you know reasonably well, you should have enough with a bit of context and a bit of focus. Note that I haven't tested this, maybe it really doesn't work well.

Would you prefer this one over the three other approaches mentioned here, the current approach, focus to hard left and the hybrid of these?

In my order of preference:

  1. Hybrid
  2. Current
  3. Hard left

I'm not sure where the midway suggestion fits in without trying it first.
My reason to put hard left at the bottom of the list is that it doesn't work well in all situations. In some apps it sounds great but in other situations it's annoyingly minimalistic without scrolling. While the other two have their issues too, I feel that they are more universally applicable. However, the current and hybrid solutions both have the problem that you need to move your finger a lot as you navigate around an interface (hence the midway idea).

Now, if you'd asked me last year I would probably have put the hard left solution up much higher. But that's mostly because I liked SuperNova's "physical mode", which is still more verbose than only seeing the focus.

Long story short: can't really decide without trying the all for a month or so.

Collaborator

dkager commented May 31, 2017

Honestly, I wouldn't use such functionality since it will probably always force me to scroll somehow.

There is a parallel here. Do you always listen to everything speech has to say? That was my motivationfor suggesting the midway point. In a GUI that you know reasonably well, you should have enough with a bit of context and a bit of focus. Note that I haven't tested this, maybe it really doesn't work well.

Would you prefer this one over the three other approaches mentioned here, the current approach, focus to hard left and the hybrid of these?

In my order of preference:

  1. Hybrid
  2. Current
  3. Hard left

I'm not sure where the midway suggestion fits in without trying it first.
My reason to put hard left at the bottom of the list is that it doesn't work well in all situations. In some apps it sounds great but in other situations it's annoyingly minimalistic without scrolling. While the other two have their issues too, I feel that they are more universally applicable. However, the current and hybrid solutions both have the problem that you need to move your finger a lot as you navigate around an interface (hence the midway idea).

Now, if you'd asked me last year I would probably have put the hard left solution up much higher. But that's mostly because I liked SuperNova's "physical mode", which is still more verbose than only seeing the focus.

Long story short: can't really decide without trying the all for a month or so.

leonardder added a commit to BabbageCom/nvda that referenced this issue Jun 30, 2017

@jcsteh jcsteh closed this in #7236 Aug 1, 2017

@nvaccessAuto nvaccessAuto added this to the 2017.3 milestone Aug 1, 2017

jcsteh added a commit that referenced this issue Aug 1, 2017

You can now choose what context information is shown on a braille dis…
…play when an object gets focus using the new "Focus context presentation" setting in the Braille Settings dialog. (issue #217, PR #7236)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment