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.

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.

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.

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?

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.

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.

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).

@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?

@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.

@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.

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.