-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Access keys (mnemonics) breaking guidelines #678
Comments
A good proposal in my opinion 👍 I only have three suggested changes and a couple nit picks:
The main reason for these is that I disagree that having the indicator be a little bit earlier in the text is worth the sacrifce of memorability and intuitiveness. The proposed "View:" label text conflicts with the existing "View" Menu and in my opinion doesn't describe the purpose of what it is labeling very well and should therefore be changed imo. Further Notes (nits basically):
|
Thank you for the feedback.
I understand your argument and that's probably how I would've done it originally, but the documentation argues: ‘Because access keys aren't intended to be memorized, they are assigned to a character that is early in the label to make them easy to find, even if there is a keyword that appears later in the label.’ I would keep them as-is for this reason.
I do not see a View menu in my build (9.4.2). Did you mean the Window menu?
I understand, but the assigning of access keys can be pretty limiting, and because of this, function is proritised over form. Basically, you pick the first available letter (preferably a notable vowel or consonant), if that letter isn't already taken by a function that is more commonly used. |
This is what the UI looks like on the most recent commit*: *This screenshot was taken on #674 (so not on main directly), but the UI is the same except for the two dropdowns below the search bar where you select sorting mode and sorting direction, but I think these two dropdowns are unlikely to change drastically before #674 is merged |
Ah, I see. In that case, I believe the thumbnail size options could probably be moved to the View menu (based on how Windows Explorer does it, at least). |
"access keys aren't intended to be memorized" Why? I ask, because I don't think that prioritising the initial "discovery" of the access key over its memorability makes sense. After all, reading 15 characters the first time couple times and reading 0 characters after that (because I am able to remember the keybind) is better than reading 8 characters every couple of times I want to use the keybind because I can't remember it well. I would very much like to understand the motivation for this though. |
Access keys are an accessibility feature, not a power-user feature. Keyboard shortcuts are meant to be memorable, while access keys are supposed to replace mouse navigation. |
I think putting this in a submenu under "View" would be fine, especially since this is most likely not used very often anyways, however I don't think doing things just because MS does them is a good idea in general. |
And I never said otherwise.
That is the literal purpose of keyboard shortcuts.
Yes, but why shouldn't Access Keys be? Edit: I feel this came out a bit more snarky then I would like, so I just want to reiterate: I would love to understand why MS prioritises this way, but MS has kind of lost my trust in them making good, thoughtful decisions, so since I don't understand the motivation myself I would need to see an explanation before I am convinced. (That said it's @CyanVoxel's decision in the end, so take that for what you will) |
I see where you're coming from, but if it helps, these guidelines and practices go way back, from before I personally have lost my confidence in them. If you would like memorable keyboard shortcuts, that's what, well, keyboard shortcuts are for. And you're welcome to create more if you feel some are missing. Keyboard shortcuts are more of an extension to mouse navigation, to make the most commonly used operations even quicker to execute. Access keys, on the other hand, are meant to be a complete replacement for a mouse, and a better alternative to just spam-tapping Tab or the arrow keys until you get to the option you want to get to. Access keys are meant to be scanned with your eyes, not remembered. If, with mouse navigation, you can remember that, say, the nth option of a menu is what you want, you can quickly scan the beginning of that row with your eyes and find the appropriate access key for it as well. |
I think I understand where you are coming from - and you know what, as far as I am concerned, let's just do it that way as you have clearly looked into this more than I have. |
Checklist
TagStudio Version
Alpha 9.4.2
Operating System & Version
Windows 11 Pro 22631.4602
Description
Some of the access keys used in menus break Microsoft's guidelines. I believe respecting those guidelines would be better for accessibility.
Expected Behavior
My observations and suggestions are as follows:
File menu
* I would suggest Backup instead, but it's better to pick and earlier word for discoverability. (Perhaps it might be worth shortening this to Save Backup?)
Edit menu
* ‘All’ is prioritised here by convention.
Tools menu
Macros menu
Window menu
Help menu
Add Tag window (Ctrl + T)
File Extensions window
* Esc should be the access key here (unlabelled).
Additionally, the commit buttons should be presented in the following order: Save, Cancel.
Library Tags window
* Esc should be the access key here (unlabelled).
Fix Unlinked Entries window
* By convention (‘Select All’), and this also solves a conflict with Refresh Duplicate Entries.
** It is better to avoid thin letters for visibility, and D wasn't a conflicting letter, anyway.
*** Esc should be the access key here (unlabelled).
Fix Duplicate Files window
* Esc should be the access key here (unlabelled).
Create Tags From Folders window
Additionally, a Cancel button (accessed with Esc) would be nice here.
In addition to all this, the main window of the program could use some access keys as well:
* The Back and Forward actions are conventionally accessed with Alt + ← and Alt + →
Steps to Reproduce
Logs
No response
The text was updated successfully, but these errors were encountered: