← Back to team overview

neos team mailing list archive

[Bug 516180] Re: (FR) Support Keyboard shortcuts

 

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

-- 
(FR) Support Keyboard shortcuts
https://bugs.launchpad.net/bugs/516180
You received this bug notification because you are a member of Team
N.E.O.S., which is subscribed to RevAger.

Status in RevAger: New
Status in RevAger 1.3 series: New
Status in RevAger 1.4 series: New

Bug description:
Yesterday I received some feedback from a user, who complained about RevAger not supporting keyboard shortcuts. Although this feedback was based on Version 1.1, I think that the problem still persists.

What's your opinion? I think adding Shortcuts should be not a big deal from the implementation side?





References