(FR) Support Keyboard shortcuts

I would suggest to include this feature already in the 1.3 release, because the implementation effort should be rather small.

I think first of all we should collect suggestions where new keyboard shortcuts may be useful. For instance inside the mainframe we have implemented keyboard shortcuts already (save review, add attendee, add meeting etc.). We can think about an implementation of some more shortcuts inside the protocol window (e.g. new finding, add aspect, add attachment etc.).

Hmm, no feedback anymore!? ;) I think it's a good idea to postpone this "mini-FR" to 1.3.1 (minor release). Of course the implementation is quite simple, but it will definitely take some time to create a good blueprint for this FR.

I fully support the idea of adressing this issue in 1.3.1 :-)

Ok, let's discuss the Escape and Enter keys stuff here ;) (and not in Bug 592755)

> - which version of RevAger did you try? (propably 1.2.1 or 1.3 RC2)
RevAger: 1.3RC2
OS: Windows 7, 32-bit
JRE: 1.6.0_17-b04

> - which dialogs or modes are affected?
Almost every single dialog I've encountered so far. The only exceptions are the "Open File" and "Save File" dialogs which are provided by the runtime.

> - what behavior would you have expected instead, when pressing Enter or ESC?
Now that's simple ;)
Enter: equivalent to "Confirm" or "OK"
Esc: equivalent to "Cancel" or "Close"

I fully agree with Igor - we really should support these basic Enter and Esc keystrokes throughout the application.

Johannes: I guess now we have some of the wanted suggestions.

Next suggestion: support mnemonics for the main menu. Like Alt-F, X for File -> Exit.

Be careful, though. Mnemonics are subject to i18n and l10n... In German, it's Alt-D, E (Datei -> Beenden), and you don't really want to know what it is in Russian ;)

And Ctrl+Shift+S for "Save Review As...".

And F1 for help. Ideally, context-sensitive ;) But at least for "Help -> Contents" menu item.

Now we have a few ideas, so we can start to create a blueprint.

But I think we should definitely concentrate on some "basic support" for keyboard shortcuts like the dialogs (yes, no; confirm, cancel etc.) or the protocol window at the moment. Supporting language-dependent mnemonics is a great idea, but after the 1.3 release we will focus on re-designing the whole application. Of course we are going to consider this kind of suggestions, but we do not plan to implement new complex features after the 1.3 release.

So, please feel free to report usability issues like this, but we cannot guarantee to implement improvements really soon. ;)

Thanks for the reply. What you suggest seems reasonable. Keyboard support is IMHO not that easy; it's not just an implementation bug you can fix by adding 2 LOC, it's a full-blown _design_ issue.

I'd also like to provide some background on this as I kind of started all this keyboard stuff (the feedback Daniel mentions in the bug description was from me ;))

At the time the bug was reported, I used to have a review of our spec every 2 weeks (and that literally for months). We use a somewhat relaxed review process - for example, no explicit aspects - because we didn't feel it was worth it for this project (maybe next time ;)). used Trac tickets as our findings management tool. This worked quite well, but has some drawbacks as Trac is a bug tracker, not a review manager. In most reviews, I was the one typing all the tickets in.

I evaluated RevAger, and we ended up not using it for two reasons, in that order:
1. No sensible keyboard-only findings logging support.
2. No support for "simplified reviews" (this seems to be somewhat resolved as of 1.3, I didn't have enough time yet to fully evaluate it).

I could have worked around the process issue, but the lack of keyboard support for logging was an absolute show stopper for me. You see, if you are the guy sitting there at the keyboard in the review, you are the one who four other people are waiting for and thus under a constant pressure. It doesn't matter that those four people just spent half an hour discussing whether some label should say "foo" or "bar" - once they're done, it matters that it get logged NOW so they can move on to the next label. So for the log person, there is ultimately only one issue: time per entry.

And no matter how cool a GUI and how many icons with cool gradients in them you have and how cool and thought-out process you implement - if you force me to switch 8 times between keyboard and mouse for a single entry, I will refuse to use your tool (or any other tool). It's that simple. Because it puts me under even more pressure and makes the reviews feel slow for everybody. In case of doubt, I'd rather switch back to paper and pencil.

Trac isn't that good in this respect either, but it at least provides somewhat sensible Tab ordering once you're in the main form which is a huge help. Plus it has less bells and whistles so I don't enter stuff I can't enter - which is a problem for the log quality, but an advantage for time.

Back to RevAger - if you're redesigning, redesign with keyboard in mind, at the very least for the logging process. Plus basic conventions like Enter/Esc for dialogs and mnemonics for menu items and components, and Tab ordering. This redesign can be a chance to get it _right_ - and hopefully I made myself clear about how crucial this is, at least from my point view. And quite frankly, I think you _need_ a redesign to provide good keyboard support for the logging window. It isn't just about calling someAction.setMnemonic(), there's much more to it (like focus management stuff you don't really need to care about if you only think about the mouse). For me, it was obvious after 15 minutes that RevAger wasn't designed with keyboard in mind. So it's fine by ...

Thanks a lot for your detailed feedback, Igor! :) This kind of background information helps us a lot in order to improve the application and its usability in the long term. We will definitely consider this topic when re-designing the application and we will keep you informed when we start to specify and design the keyboard support.