Comment 11 for bug 516180

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 me if it'll be 1.4 or even 1.5 - provided it works smoothly then :)

OK, enough time spent bitching around :) Although I don't have much resources, I could help with the blueprints and all this keyboard design stuff. I even look forward to it ;)