Ticket #788 (new enhancement)

Opened 19 months ago

Last modified 19 months ago

Automatically move mouse with flat review

Reported by: aleksey_s Owned by:
Priority: minor Milestone:
Component: Core Version:
Keywords: Cc:
Operating system: Blocked by: #58
Blocking:

Description

A mode should be implemented that, when switched on, will move the mouse automatically when user reviews the flat representation. It will save a few keypresses when one wants to click a lot in the application.

Change History

comment:1 Changed 19 months ago by aleksey_s

  • Blocked by 58 added

Since it seems to be not very difficult to implement, but it will bring a great convenience for users, I would like to see it taken for 2010.2.

comment:2 Changed 19 months ago by mdcurran

Would you be happy simply with a "Mouse follows review cursor" checkbox in mouse settings dialog?

I agree it would be very easy to do.

Though I am worried that some of this stuff will be scattered across dialogs.
In VoiceOver? all the navigation routing checkboxes are in the one dialog.
Do we wish to consider doing this?
However this is out of scope for this ticket, for now I guess we can only go with the checkbox either in the mouse settings dialog or the review cursor dialog. Which one is best?
Perhaps the Review Cursor dialog suits better now I think about it.

comment:3 Changed 19 months ago by jteh

I vote Review cursor dialog.

comment:4 follow-up: ↓ 6 Changed 19 months ago by mdcurran

Having played with this idea a bit, I am not too sure its all that useful.
There is a rather annoying side-affect when dealing with menus, and anything else that react when the mouse is moved over them.
Specifically for menus, if the mouse moves when the review cursor moves (and if focus moves navigator object is enabled, which it is by default) then the mouse moves when the focus moves. However, when arrowing down a menu and you highlight a submenu, that submenu opens and the focus is placed on the first item. If that item is itself a submenu, it happens again.
This is because if you run the mouse down a menu, each item is highlighted, and any submenus are opened automatically.

I think, its easy enough for the user to move the review cursor where they want, and then press move navigator object to mouse.
At least then they are physically making the decision to deal with any consequence that arrises from placing the mouse at that point.
Alternatively, we could just move the mouse from the actual scripts, rather than in setReviewPosition/setNavigatorObject, which would I guess have the same affect, but not confuse the focus.
But, this would mean quite a bit of code duplication... unlesss perhaps setReviewPosition and setNavigatorObject could take a keyword argument... something like interactive=True, meaning that the user deliberately set it, rather than say focus/selection.

comment:5 Changed 19 months ago by jteh

Alternatively, we could implement the setting and document that it shouldn't be used in conjunction with focus moves navigator/review.

How does VoiceOver on the Mac deal with this?

comment:6 in reply to: ↑ 4 ; follow-up: ↓ 7 Changed 19 months ago by aleksey_s

Replying to mdcurran:

Having played with this idea a bit, I am not too sure its all that useful.

I am sure it is useful, however, we should decide how to deal with cases you found.

Specifically for menus, if the mouse moves when the review cursor moves (and if focus moves navigator object is enabled, which it is by default) then the mouse moves when the focus moves.

This brings a new problem. When the application decides to set focus on something when user is working with the flat review, NVDA will "turn off" the flat review and bounce the review cursor to the object in focus. This behavior may be confusing for the user. Or do i misunderstand it? What happens with the position of the review cursor in the flat review when the navigator object moves?

However, when arrowing down a menu and you highlight a submenu, that submenu opens and the focus is placed on the first item. If that item is itself a submenu, it happens again.

This is how I see it:

  • The "Review cursor moves mouse" mode is turned on
  • user moves review cursor to the menu item with submenu
  • since mouse is set to the menu item with submenu, the submenu opens automatically
  • the focus is set to the first item in the submenu, but the review cursor (and mouse cursor too) stays on the top level item, since user hasn't moved it from there
  • Therefore, second submenu doesn't open

This behavior I saw in jaws with the jaws-cursor.

I think, its easy enough for the user to move the review cursor where they want, and then press move navigator object to mouse.

You mean "move mouse to the navigator object", right?

At least then they are physically making the decision to deal with any consequence that arrises from placing the mouse at that point.

I think by enabling that mode users already made the decision. Anyway, I find myself dealing with menus is mutch easier with using traditional windows way (arrowing) rather than moving around with the flat review.

unlesss perhaps setReviewPosition and setNavigatorObject could take a keyword argument... something like interactive=True, meaning that the user deliberately set it, rather than say focus/selection.

Will it behave as I described above then?

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 19 months ago by jteh

Replying to aleksey_s:

This brings a new problem. When the application decides to set focus on something when user is working with the flat review, NVDA will "turn off" the flat review and bounce the review cursor to the object in focus. This behavior may be confusing for the user.

The idea is that flat review isn't a "mode" as such. Rather, it is something the user chooses to do at a particular point in time. We did this because we still believe that, particularly with modern applications, object navigation is still a more effective way of accessing controls. Also, flat review won't work everywhere, so having it enabled all the time doesn't make sense.

  • The "Review cursor moves mouse" mode is turned on
  • user moves review cursor to the menu item with submenu
  • since mouse is set to the menu item with submenu, the submenu opens automatically
  • the focus is set to the first item in the submenu, but the review cursor (and mouse cursor too) stays on the top level item, since user hasn't moved it from there

This behavior I saw in jaws with the jaws-cursor.

That's because JAWS doesn't tether its mouse (JAWS) cursor to the focus (PC cursor) by default. This is actually the other alternative: we implement a Mouse moves review cursor option, but make it clear that it is not wise to have both it and Focus moves navigator enabled simultaneously.

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 19 months ago by mdcurran

Replying to jteh:
This is actually the other alternative: we implement a Mouse moves review cursor option, but make it clear that it is not wise to have both it and Focus moves navigator enabled simultaneously.
Um, we already have that option: Review cursor dialog -> follow mouse checkbox. Unless I'm not following what you're saying. However, if the mouse moves with this option enabled, the review cursor will always be thrown in to the deepest object at the point of the mouse, rather than staying on the flat review object if thats where you were.
I think, we do need to consider the idea of a mode a bit more I think... before this is perfect.

comment:9 in reply to: ↑ 8 Changed 19 months ago by jteh

Replying to mdcurran:

This is actually the other alternative: we implement a Mouse moves review cursor option, but make it clear that it is not wise to have both it and Focus moves navigator enabled simultaneously.

Um, we already have that option: Review cursor dialog -> follow mouse checkbox.

Err, I meant Review cursor moves mouse. Sorry.

Note: See TracTickets for help on using tickets.