Monday, November 25, 2024

Initial Thoughts on "Shortcut Editing" UI's

Is it just me, or do pretty much all the "Shortcut Editor" UI's in various apps suck?

I don't claim to have a fully fleshed out + well considered + tested alternative in this case (unlike with many of the UI problems that I've spent some time toying with), but just to throw some ideas out there to kickstart a conversation about these UI's that I think as an industry we need to have.

So, without further ado, here are a few ideas for how I'd go about making Shortcut Editor UI's better if / when I try to design one next time.

 


1) When trying to replace the shortcut for an action that already has a shortcut assigned and/or there may also be a conflicting action assigned to the same shortcut:  If there's a potential conflict (i.e. the change will overwrite another existing hotkey), instead of just replacing it (and then leaving the user trying to track down what they lost), I usually just end up wanting to swap them.

So, I think it makes sense that the should instead be to ask if the user wants to swap the two actions (i.e. new behaviour), or whether they want to overwrite the existing mapping with the new one we're introducing (i.e. "Overwrite" - current behaviour), or whether nothing should be done (i.e. "Cancel").


2) Graphical Keyboard Display, with all "taken" / "assigned" keys for the current mode / view tagged + labelled on that

Currently most of these shortcut managers inevitably just show a massive tree view, grouped by functional-area categories, and then drilling down into a list of event mappings defined for that mode.

While this is great when you know a function (by name) that you want to modify or add new mappings for, it does have several critical weakensses:

  * A) You need to already know the name of what you're searching for. Otherwise, you're trying to find out what feature might use that mapping, by searching for the key in question. This often leads to B)

  * B) When you want to change the hotkey mappings, you'll inevitably end up wondering:

           - "Are there any un-mapped / free keys I can assigned my feature to"?

           - "Are thee any existing ones overlapping with what I'm trying to do?


(Yes, I later realised that when not everyone uses US-EN QWERTY, this will inevitably cause some massive problems for quite a few users with weird setups, OR would impose a massive maintenance burden for any app trying to support this without some good shared library + database OR a suitable API that each machine can report it keyboard layout via)


3) Sometimes the mappings you need to create a non-obvious, due to the internal characteristics of the event-system you're working with from the UI toolkit.    This especially applies for things like "press vs release" mappings, but also a few other things like hat

No comments:

Post a Comment