Currently you can zoom the diagram using the numeric keypad's + and - keys. You can also move around the diagram using the arrow keys - so long as you have selected a box first.
However it should be possible to move the diagram (without having to drag) by using the arrow keys. This will be exactly like moving around a document to a user. This is something that everyone does already so it's a concept that they can easily understand. Many programs allow moving around a workspace larger than the screen and so users would use it without thinking. I must admit I've only just got used to the fact the FH doesn't scroll a diagram with the keyboard after having used it intensively for a month.
Also, the normal + and - keys should perform the zoom actions as well as the numeric keypad keys. In addition it would be nice if there was a reset to 100% key as well. The * key on the normal keyboard as well as the numeric keypad is one suggestion. This would be useful to laptop users which don't have a numeric keypad.
ID:2146
* Diagram manipulation to be more keyboard driven
-
Jane
- Site Admin
- Posts: 8442
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Diagram manipulation to be more keyboard driven
The cursor keys already move around the boxes, so I am not sure how you could also scroll regardless of boxes at the same time with out holding another key as well.
I tend to use the mouse and hold down the spacekey to grab and move. I find this easy on the laptop as works well with the trackpad.
Zooming can also be done using
Ctrl+K Zoom Out (Diagram Window).
Ctrl+L Zoom In (Diagram Window).
Remember the + is a shifted character on the normal keyboard, but the - is not, and they are different on non UK keyboards from memory.
I tend to use the mouse and hold down the spacekey to grab and move. I find this easy on the laptop as works well with the trackpad.
Zooming can also be done using
Ctrl+K Zoom Out (Diagram Window).
Ctrl+L Zoom In (Diagram Window).
Remember the + is a shifted character on the normal keyboard, but the - is not, and they are different on non UK keyboards from memory.
-
ChrisBowyer
- Superstar
- Posts: 389
- Joined: 25 Jan 2006 15:10
- Family Historian: None
Diagram manipulation to be more keyboard driven
I would expect scrolling to be done with either Shift or Ctrl with the arrow keys, neither of which have any different meaning at present
Diagram manipulation to be more keyboard driven
Jane, thanks for the info about the use of the space bar. Not a very common thing in Windows programs so not something I thought to try - plus its use is hidden in the help. I know, RTFM, but to be honest I have used many different Windows programs and I can use many new ones without resorting to help because they follow defacto rules about how things are done. Using the space to toggle grab mode is not one of them, the normal (that I've come across) is to allow grabbing with the middle mouse key.
Zooming with Ctrl-K and L is not intuitive at all, and not something I would even think to look in the help to find the key assignments. + and - are the normal keys, and I understand that + is shifted, but it's the concept not the actual key value that's important. FH in reality would use - to zoom out and = (unshifted + ) to zoom in but the user just presses the keys marked with + and -. Many graphic viewing programs use this concept.
Regarding the use of the arrow keys, the diagram should be able to scroll when a box is NOT selected. If a box is selected, work as it currently does and jump from box to box. When no box is selected, allow the digram to move like it does when you use the mouse on the scroll bars. Again, something which many graphic viewing programs do. Use of Shift/Ctrl or Alt could be made to make the scrolling action with the arrow keys faster. Such key modifiers could also be used in 'box selected' mode to jump from first child to last child which is another wish list item already (#264).
Zooming with Ctrl-K and L is not intuitive at all, and not something I would even think to look in the help to find the key assignments. + and - are the normal keys, and I understand that + is shifted, but it's the concept not the actual key value that's important. FH in reality would use - to zoom out and = (unshifted + ) to zoom in but the user just presses the keys marked with + and -. Many graphic viewing programs use this concept.
Regarding the use of the arrow keys, the diagram should be able to scroll when a box is NOT selected. If a box is selected, work as it currently does and jump from box to box. When no box is selected, allow the digram to move like it does when you use the mouse on the scroll bars. Again, something which many graphic viewing programs do. Use of Shift/Ctrl or Alt could be made to make the scrolling action with the arrow keys faster. Such key modifiers could also be used in 'box selected' mode to jump from first child to last child which is another wish list item already (#264).
-
Jane
- Site Admin
- Posts: 8442
- Joined: 01 Nov 2002 15:00
- Family Historian: V7
- Location: Somerset, England
- Contact:
Diagram manipulation to be more keyboard driven
Just on the grab, it's supported that way in Adobe Reader.
Diagram manipulation to be more keyboard driven
True, but Adobe Reader also supports dragging with the middle mouse button as well as the left mouse button.
What I'm trying to get across is the usability factor. What is the most likely thing to do with a diagram - move it around to look at different parts. Supporting this feature in the many common ways that all other Windows programs do means it makes it easier for users of FH to get to grips with it.
Also, the usability factors means that the fact that dragging is not available until you click on the drag button makes it irritating for new users since they have to do any extra step. When they want to edit, the drag mode is reset meaning the have to click the button yet again. Yes, the spacebar is not an extra click, but to the new user it's not that obvious because they see the drag button. Why look at the help when the drag button is there on the screen.
Another point in the irritability factor is the fact that in drag mode you can't double click on an individual to edit them. You can right click which cancels drag mode, but then you have to right click AGAIN to get the pop-up menu. If the drag mode was implemented naturally by the middle mouse button then you wouldn't need to cancel drag mode to edit an individual - it would be always on.
One final point about the space bar and drag mode is that it mixes keyboard and mouse actions together. In terms of usability the best thing is to use mouse actions or keyboard actions seperately, not combined. For instance in the sources pull out on the property dialog you can TAB (keyboard) from the Entry Date to the Note, but when you want to Back-TAB you HAVE to use the mouse to click away from it. Having to keep switching from using the keyboard to the mouse means you have to reset your hand position (plus find the mouse cursor again) which slows down the speed at which you use the program. That's ok for new users, but as you speed up and get more experienced it becomes an irritation factor. On the diagram there is not really any text entry so mouse actions should predominate. On the property dialog since it's mostly text entry, so ALL navigation should be possible by keyboard alone (with the mouse still available).
I hope that helps explains the reasoning behind my request.
Jon
What I'm trying to get across is the usability factor. What is the most likely thing to do with a diagram - move it around to look at different parts. Supporting this feature in the many common ways that all other Windows programs do means it makes it easier for users of FH to get to grips with it.
Also, the usability factors means that the fact that dragging is not available until you click on the drag button makes it irritating for new users since they have to do any extra step. When they want to edit, the drag mode is reset meaning the have to click the button yet again. Yes, the spacebar is not an extra click, but to the new user it's not that obvious because they see the drag button. Why look at the help when the drag button is there on the screen.
Another point in the irritability factor is the fact that in drag mode you can't double click on an individual to edit them. You can right click which cancels drag mode, but then you have to right click AGAIN to get the pop-up menu. If the drag mode was implemented naturally by the middle mouse button then you wouldn't need to cancel drag mode to edit an individual - it would be always on.
One final point about the space bar and drag mode is that it mixes keyboard and mouse actions together. In terms of usability the best thing is to use mouse actions or keyboard actions seperately, not combined. For instance in the sources pull out on the property dialog you can TAB (keyboard) from the Entry Date to the Note, but when you want to Back-TAB you HAVE to use the mouse to click away from it. Having to keep switching from using the keyboard to the mouse means you have to reset your hand position (plus find the mouse cursor again) which slows down the speed at which you use the program. That's ok for new users, but as you speed up and get more experienced it becomes an irritation factor. On the diagram there is not really any text entry so mouse actions should predominate. On the property dialog since it's mostly text entry, so ALL navigation should be possible by keyboard alone (with the mouse still available).
I hope that helps explains the reasoning behind my request.
Jon