4 ms·
the problem cited in the article is performance. a "help" dialog shouldn't take several seconds to open, it shouldn't take foreground control, and you shouldn't
by woodrowbarlow 9y ago
the problem cited in the article is performance. a "help" dialog shouldn't take several seconds to open, it shouldn't take foreground control, and you shouldn't have to wait for it to finish opening in order to close it. and you definitely shouldn't have to move your hand to the mouse to close something that was opened by an accidental keystroke.
if the view doesn't get obstructed and you could simply tap F1 a second time (or Esc) and instantly be back to what you were doing, i think the UX problem would be solved.
in firefox, i sometimes hit F12 on accident -- but i can just tap it again to close the dev tools, even if it hasn't finished loading. that's decent UX.
- dmitriid 9y agoNo.. The problem cited in the article is: a common operation that is invoked hundreds of times a day is bound to F2. An uncommon operation that breaks the user's flow is bound to F1. Users keep hitting F1 by accident. The only proper and decent UX in this case is to remove the source of the error. You do that by removing the binding of F1
- woodrowbarlow 9y ago> that breaks the user's flow this is the problem. and it breaks the user's flow because it obscures the work area and can't be instantly dismissed. there's nothing wrong with putting relatively uncommon actions next to common actions on the keyboard as long as the actions don't break the user's flow.
- dmitriid 9y ago> as long as the actions don't break the user's flow. This. Yet you propose to keep the action that breaks the user flow even if it's often triggered by mistake ;) I propose to remove the action that breaks the user flow.