Skip to content
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

Open
3 tasks done
smileyhead opened this issue Jan 1, 2025 · 10 comments
Open
3 tasks done

[Bug]: Access keys (mnemonics) breaking guidelines #678

smileyhead opened this issue Jan 1, 2025 · 10 comments
Labels
Priority: Medium An issue that shouldn't be be saved for last Type: Bug Something isn't working as intended Type: UI/UX User interface and/or user experience

Comments

@smileyhead
Copy link
Contributor

Checklist

  • I am using an up-to-date version.
  • I have read the documentation.
  • I have searched existing issues.

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

Current State Comment Suggestion
Open/Create Library
Save Library
Save Library Backup Conflict with Save Library.* Save Library Backup
Refresh Dictionaries
Close Library

* 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

Current State Comment Suggestion
New Tag ‘New’ should be prioritised here. New Tag
Copy Fields
Paste Fields
Select All Missing access key.* Select All
Clear Selection Missing access key. Clear Selection
Delete Selected File(s) Missing access key. Delete Selected File(s)
Manage File Extensions Missing access key. Manage File Extensions
Manage Tags Missing access key. Manage Tags

* ‘All’ is prioritised here by convention.

Tools menu

Current State Comment Suggestion
Fix Unlinked Entries
Fix Duplicate Files ‘Duplicate‘ should be prioritised here. Fix Duplicate Files
Create Collage Missing access key. Create Collage

Macros menu

Current State Comment Suggestion
Autofill Missing access key. Autofill
Sort Fields
Folders to Tags Missing access key. Folders to Tags

Window menu

Current State Comment Suggestion
Open Library On Start Missing access key. Open Library On Start
Show Recent Libraries Missing access key. Show Recent Libraries

Help menu

Current State Comment Suggestion
Visit GitHub Repository Missing access key. Visit GitHub Repository

Add Tag window (Ctrl + T)

Current State Comment Suggestion
Name Missing access key. Name
Shorthand Missing access key. Shorthand
Aliases Missing access key. Aliases
+ Missing access key. Should be changed for accessibility. Add
- Missing access key. Should be changed for accessibility. Remove
Color Missing access key. Color

File Extensions window

Current State Comment Suggestion
List Mode Missing access key. List Mode
Add Extension
Cancel Missing access key.* Cancel
Save Missing access key. Save

* Esc should be the access key here (unlabelled).
Additionally, the commit buttons should be presented in the following order: Save, Cancel.

Library Tags window

Current State Comment Suggestion
Search Tags Missing access key. Search Tags
Done Missing access key.* Done

* Esc should be the access key here (unlabelled).

Fix Unlinked Entries window

Current State Comment Suggestion
Refresh All ‘All’ should be prioritised here.* Refresh All
Search & Relink
Delete Unlinked Entries The access key can be moved.** Delete Unlinked Entries
Refresh Duplicate Entries Missing access key. Refresh Duplicate Entries
Merge Duplicate Entries
Done The access key can be moved.*** Done

* 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

Current State Comment Suggestion
Load DupeGuru File
Mirror Entries
Done The access key can be moved.* Done

* Esc should be the access key here (unlabelled).

Create Tags From Folders window

Current State Comment Suggestion
Open All Missing access key. Open All
Close All Missing access key. Close All
Apply

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:

Current State Comment Suggestion
< Missing access key.* <
> Missing access key.* >
Search Entries Missing access key. Search Entries
[Search Mode drop-down] Missing label and access key. Search Mode:
[Thumbnail Size drop-down] Missing label and access key. View:

* The Back and Forward actions are conventionally accessed with Alt + and Alt +

Steps to Reproduce

  1. Open TagStudio
  2. Check menus

Logs

No response

@smileyhead smileyhead added the Type: Bug Something isn't working as intended label Jan 1, 2025
@Computerdores
Copy link
Collaborator

A good proposal in my opinion 👍

I only have three suggested changes and a couple nit picks:

  • "Save Library Backup" --> "Save Library Backup" (File Menu)
  • "Search Mode" --> "Search Mode"

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

  • I believe Qt doesn't support having Esc as an Access Key, however it could very well be implemented as a shortcut instead
  • I kind of dislike "Clear Selection" for the same reasons that I suggested the other changes, but I also don't have a better idea

@smileyhead
Copy link
Contributor Author

Thank you for the feedback.

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.

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.

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.

I do not see a View menu in my build (9.4.2). Did you mean the Window menu?

I kind of dislike "Clear Selection" for the same reasons that I suggested the other changes, but I also don't have a better idea

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.

@Computerdores Computerdores added the Type: UI/UX User interface and/or user experience label Jan 1, 2025
@Computerdores
Copy link
Collaborator

Computerdores commented Jan 1, 2025

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.

I do not see a View menu in my build (9.4.2). Did you mean the Window menu?

This is what the UI looks like on the most recent commit*:
image

*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

@smileyhead
Copy link
Contributor Author

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

@Computerdores
Copy link
Collaborator

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.

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.

"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.

@smileyhead
Copy link
Contributor Author

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.

@Computerdores
Copy link
Collaborator

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

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.

@Computerdores
Copy link
Collaborator

Computerdores commented Jan 1, 2025

Access keys are an accessibility feature, not a power-user feature.

And I never said otherwise.

while access keys are supposed to replace mouse navigation.

That is the literal purpose of keyboard shortcuts.

Keyboard shortcuts are meant to be memorable

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)

@smileyhead
Copy link
Contributor Author

smileyhead commented Jan 1, 2025

MS has kind of lost my trust in them making good, thoughtful decisions

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.

@Computerdores
Copy link
Collaborator

Computerdores commented Jan 1, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Medium An issue that shouldn't be be saved for last Type: Bug Something isn't working as intended Type: UI/UX User interface and/or user experience
Projects
Status: 🛠 Ready for Development
Development

No branches or pull requests

3 participants