Design: Hotkeys

[joethreepwood]

Little note of design feedback which came up on a call with @marcushyett-ph and @lottiecoxon. Essentially, I raised the question of whether hot keys in the app are providing actual value. What we found was:

• Hotkeys are used by about 20% of PostHog employees
• Hotkeys are used by about 3% of PostHog users (excl. employees)
• The 3% of users who try hotkeys overwhelmingly only try it once (may be accidental)

This is true for both the signalled hotkeys (F for Funnels) and the hidden hotkeys (G for extra hotkeys).

Given that hotkeys are basically unused by users, it would seem worth removing the interface clutter. I understand there may be protest from the 20%, but I'd challenge we need to put customer experience first. Maybe we could put this feature behind a flag and enable it for ourselves only?

Tagging @clarkus as it seems an interface issue.

[paolodamico]

A potential approach here is to keep the hotkeys and just remove the indicators (not strongly against removing them altogether), but I would challenge we revisit this as we work out the new architectural design. At worst this is just a bit distracting now. Also @joethreepwood quick feedback, it'd be incredibly helpful for anyone reading this if you could link your graphs.

[clarkus]

I don't have a strong opinion on this - I think generally if we include access keys or hot keys, we should follow best practices and guidance especially as they relate to accessibility. I do think we could be a little less up-front with communicating the key associations. I agree with @paolodamico that this is something that could roll into a longer term IA rework once that makes sense from a timing perspective.

[lottiecoxon]

Just a thought but in some programs (adobe + blender) they don't directly show the hotkey but it appears similar to a tooltip when hovered over for more than one or 2 seconds - I think that maybe following a similar approach would a) clean up the dashboard while b) still exposing our users to the existence of the hotkeys. I don't know if maybe I'm coming at it from a designers perspective but to me that seems the most intuitive way 🤔

[clarkus]

@lottiecoxon's point is a strong one - we can expose the keys in a way that isn't intrusive, but still discoverable. That way users can learn how they work without having to see them all the time.

[joethreepwood]

Wouldn't that just increase the likelihood that users would use them by accident?

They're pretty prominent now and getting very low usage, so I'm not sure how making them less visible would make them more valuable.

@paolodamico Sorry -- I logged this issue while on a call discussing with Marcus, who made the query. I've recreated it (or equivalent of it) here.

[lottiecoxon]

To counteract the 'accidental' hotkey fiasco, could you add a ⌘ command, a ⌥ option or ⌃ control symbol before the letter -so that pressing letters alone won't cause any change?

I think making the hotkeys more prominent or even keeping them as they are is not a good idea, imo hotkeys are for those who choose to seek them out and use them, plus they make the dashboard unnecessarily busy. I vote we make a handbook entry of app hotkeys, then on tooltips we could give the option to access a cheatsheet for PostHog hotkeys - or we could have a pop up for new users explaining hotkeys (as apart of the product onboarding)

For example this is adobes UI for hotkeys:

Screen.Recording.2021-10-18.at.10.27.08.mov

[clarkus]

Wouldn't that just increase the likelihood that users would use them by accident?

They're pretty prominent now and getting very low usage, so I'm not sure how making them less visible would make them more valuable.

They would be more valuable by not competing with other more critical elements on the page. When hot keys symbols are front and center everywhere they can distract from things like counts or other badge-like indicators to give extra meaning to content. As an example, modifiers that can describe elements on a page are counts, beta badges, inline creation actions, information marks that add affordance for learning more.

A user shouldn't really use them by accident unless they're already trying to navigation via their keyboard. The events bindings shouldn't trigger when you're focused on other editable components like form inputs. Also related to not triggering them accidentally is coming up with meaningful, non-conflicting bindings that don't map to any other default browser short cut.

TL;DR - if we provide key bindings, they should be learnable but not prioritized over other items in the page. Showing keybindings on hover, in secondary menus as descriptive text, or even providing a cheat sheet of bindings could be enough to communicate the bindings while not distracting from the rest of the product.

To counteract the 'accidental' hotkey fiasco, could you add a ⌘ command, a ⌥ option or ⌃ control symbol before the letter -so that pressing letters alone won't cause any change?

@lottiecoxon this is a good idea, but those bindings can often be specific to the operating system. We would want to come up with something approachable and simple enough for all users. Plus when you get into command + territory you're going to be competing with native bindings in the browser. It could work, but it definitely adds complexity.

[paolodamico]

That makes sense @clarkus!

I'm a bit afraid we spend too much time overthinking this, which seems generally inconsequential. Should we just comment on this on the Information Architecture Figma once it's ready?

[clarkus]

That's a good idea, @paolodamico. I'll include some concept in that work for communicating hot keys. I think there is going to be a separate area of work to ensure they don't conflict with other keys, but also to ensure they're not triggering in the wrong context. For example, if a form input is focused, shortcut key bindings shouldn't ever trigger.

[clarkus]

While working on the upcoming IA changes, I put together a quick concept for how we might expose shortcut keys in a complete way, while also being unobtrusive. The idea is to append some simple toggle somewhere in the common chrome of the product that lets a user view all shortcut keys when they want. Acting on this would show a modal or some other overlay pattern that lists and describes all the shortcuts available. That would solve for both cases - making keys easy to access and learn while not displacing or competing with other content.

https://www.figma.com/file/NHPA2hVWwaKp4eTGWdigs9/Product-Concepts?node-id=526%3A6114

[corywatilo]

I like this, but it's starting to feel like the kitchen sink up in that top right corner. (I generally think anything more than 3-4 icons in a row starts to get a little overwhelming.

Not super related to this thread but related to this mock above, it really seems like we could move the timezone thing into the user menu. Still easily visible, probably where you'd go to change your timezone in the future (when we support it), and once you see it, you probably don't need to see it again. Seems like it currently has a lot of unnecessary visual weight.

[clarkus]

Not super related to this thread but related to this mock above, it really seems like we could move the timezone thing into the user menu. Still easily visible, probably where you'd go to change your timezone in the future (when we support it), and once you see it, you probably don't need to see it again. Seems like it currently has a lot of unnecessary visual weight.

It was in the menu previously and the feedback was that it's too buried. Maybe we just need to remove it and do translation inline for all time values instead. It's most applicable when you're trying to determine the time displayed relative to your locale.

Also worth noting that we are purposefully under-loading that help component there. We don't have a ton of strategy around that yet (out of scope for this effort), but longer term we might roll the keyboard shortcuts and other instructional bits into a submenu under help.

This will also feel less packed once the design toggle is removed. It's a short term thing to help users navigate the changes, but once we're locked that won't be taking up space any longer.

Edited to include an example of how we might build out a help menu in the future. It's a restatement of our current support page, just in a menu with the addition of shortcut keys.

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[posthog-bot]

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.