Shortcut settings position

Development
1

Hello!
In the context of fixing XWIKI-16216: Allow users to rebind the shortcuts from their user profile UI, I started looking for a way to add shortcuts in the user profile interface.

I could think of two main solutions:
A. Add a category in the settings to contains only shortcuts.
In my opinion, this shortcut settings would be quite technical and a transverse category (it can influence the UX on tasks related to various features), so it would fit right after the Preferences category.

16216-proposal1
16216-proposal12560×1204 210 KB

Pro: Great discoverability for XWiki shortcuts, which is in my opinion something we could improve.
Con: We add another category. In the standard flavor, this makes the amount of categories go from 8 to 9, bringing this UI element to the really close to fully disregarding Miller’s law. I think this is a large drawback for a UI that pretty much any user will go through at some point.

B. Add a subcategory in the Preferences category

16216-proposal2
16216-proposal22560×1204 211 KB

Con: The preference category would now be too long to see fully on a single screen, the user would need to scroll down to view or edit all the preferences. Note that this is already the case for the Notification settings category.

I would probably have gone for option A if I had not started a discussion. Option A would trade off a bit of quality of user experience for feature discoverability.
I don’t think this is the last time we’re going to add a user setting, and user experience when navigating settings should not be overlooked, so maybe it’s time to switch the user interface to be able to showcase clearly more items (maybe even make this UI consistent with the Admin accordion menu?).

What solution for the shortcut settings should be the one we move forward? Do you see additional drawbacks and advantages to any of those solutions?

Thank you for your interest on this topic :slight_smile:
Lucas C.

2

+1 for option A
Imo each setting screen should have a single concern and mixing up things in the preferences is not great.
Do you plan to have a corresponding shortcut config entry in the wiki admin?

3

In my opinion this is less important because:

  • There’s a ‘code way’ to change default bindings on a wiki, described at https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/KeyboardShortcuts .
  • Shortcuts should be something that every user personalizes based on the set of tools they use (OS, browser, browser extensions, screen readers ). Except for organizations where the suite of tools is handled by one admin and they want to defined new defaults at the level of the organization, I suppose this admin would be pretty technically aware and be able to use the ‘code way’ to handle it.
  • It’s something I would expect as a user to have the same default shortcuts across different wikis :slight_smile:

This could still improve the experience for some admins, but it looks to me like it’d be way too specific of a use case to be worth the implementation, bugs and UI clutter. I don’t have plans to add a shortcut configuration at the admin level.

Thanks!
Lucas C.

4

Thanks for the proposal. Obviously, +1 for A. However having 9 entries at the end of a profile page, in my view, it’s too many and not many users visiting all sections.

5

I think we need to have more menu entries, each focused on a given topic.

However, I think we need to reuse the menu from the Admin UI and thus have 2 levels + the search box. This would solve your problem of Option A.

If you don’t have the time to do this new menu refactoring, then +1 for option A for now while waiting for it.

Thx

1 Like
6

This new menu refactoring will be heavier, and I’d rather wait for the proposal by Adina on Global Administration UI Revamp to be resolved to avoid working on this refactoring twice. I opened a new improvement ticket to keep track of this idea though :slight_smile:

Thanks for your feedback!

Lucas C.

7

Hi,

I think the section name should be more explicit. Not everyone that reads “Shortcuts” thinks about keyboard shortcuts. They can also think about “link” shortcuts that a user may want to have in a side panel for instance. So I’d use “Keyboard Shortcuts” or “Shortcut Keys”.

I agree with the others that having an accordion menu would be better, with “Keyboard Shortcuts” being a section of the “Preferences” category, for instance. Until we have this, I’d go with what’s easier to implement.

I understand you want this feature to be discoverable, and having a top level category for this certainly helps with that, BUT I think most users won’t change the default shortcut keys AND if they do it they do it once. So I don’t think it deserves to have a top level category for something you access very rarely, which is why I’m leaning towards solution B (subcategory), which will be consistent with a future accordion menu where “Keyboard Shortcuts” won’t be a top level category but a section (subcategory).

Thanks,
Marius

1 Like
8

Thanks for this insight!

Indeed, in this regard, solution B makes more sense :slight_smile:
I’ll go along with solution B since it’s slightly easiest to implement and no major negatives were highlighted about it. The concern I had about making this section too large is barely noticeable if we put those preferences as the last ones. Moreover, it doesn’t rely on updating the user settings menu for the solution to be complete.

1 Like