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

Update support and keyboard documentation #157

Open
chibicitiberiu opened this issue Mar 7, 2019 · 10 comments
Open

Update support and keyboard documentation #157

chibicitiberiu opened this issue Mar 7, 2019 · 10 comments
Labels
Enhancement help wanted Issues identified as good community contribution opportunities needs spec Pri: 2

Comments

@chibicitiberiu
Copy link

chibicitiberiu commented Mar 7, 2019

Problem Statement
Some users are much quicker when navigating with a keyboard, instead of the mouse. While the application has many keyboard shortcuts, some improvements could be made to improve it.

Evidence or User Insights

Proposal
Here is what I'm proposing:

  1. Improve the discoverability of keyboard shortcuts. Currently, pressing the 'alt' key reveals what keys will press, which is great:
    image

It would be better if there was a way of displaying all the keys, including the various functions, or changing modes. For example, the F1 key (which is traditionally bound to bringing the 'help' for the application) is completely unbound; it would be useful if it showed a list of the keyboard shortcuts, or perhaps some labels near the keys similar to what happens when pressing 'Alt'.

  1. Assign keys to the buttons which don't have any. For example, in the "Programmer" view, there is no key to toggle between "keypad" and "bit" modes. Also, in the "bit" mode, you can't type any number using the keyboard (you could in the old win7 calculator).

  2. Extensively test keyboard navigation. Recently, I found Numpad 'enter' key should always be equivalent to pressing '=' #152 which is a pretty annoying issue for people who use the keyboard extensively.

Goals
Users who are more comfortable with using the keyboard can use Calculator without having to touch the mouse, and can do their work much more quickly.

Non-Goals

Low-Fidelity Concept
Here is a crudely drawn concept for proposal 1:
image

Alternatively, this is another way of implementing the proposal:
image

@MicrosoftIssueBot
Copy link
Collaborator

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

@grochocki
Copy link
Contributor

Thanks for the feature suggestion! This is really well thought-out, and we really appreciate it. Calculator currently uses a mix of Access Keys and Keyboard Accelerators, which are intended for slightly different purposes:

Access Keys

Access keys are keyboard shortcuts that improve the usability and the accessibility of your Windows applications by providing an intuitive way for users to quickly navigate and interact with an app's visible UI through a keyboard instead of a pointer device (such as touch or mouse).

Keyboard Accelerators

Accelerator keys (or keyboard accelerators) are keyboard shortcuts that improve the usability and accessibility of your Windows applications by providing an intuitive way for users to invoke common actions or commands without navigating the app UI.

We should consider how to balance the use of both of these types of keyboard interactions to provide the best experience for users who prefer to use the keyboard. Let's keep this idea open for discussion so the community has the chance to provide feedback.

@ChaosBladeCoder
Copy link

I never even thought of pressing the ALT key to get at the keyboard accelerators. My first instinct was always to hover the mouse over the keys, but unfortunately this doesn't display anything at all.

The keyboard accelerators would be a lot more discoverable if they were displayed on mouse hover.

@ghost
Copy link

ghost commented Jun 5, 2019

We reviewed the pitch and would love to explore this idea further! The pitch is a great start, but there are still some open questions. Moving this into planning to iron out some of those details. A human will follow up with some feedback on your pitch shortly. Keep in mind that not all ideas that make it into the planning phase are guaranteed to make it to release. For more information on next steps, check out our spec workflow.

@grochocki
Copy link
Contributor

We would love to make it easier for users to understand what keyboard shortcuts are available, but we also want to make sure that we follow the proper guidance in regards to the use of access keys and keyboard accelerators. We would like to propose the following:

  • Add a link in the about dialog to the app support and keyboard shortcut documentation online
  • Audit/improve the documentation by iterating on the content in this project. Once the documentation is up-to-date and validated, we'll update the support documentation on support.microsoft.com with the latest changes.

I created calculator-specs/supportdocs to track progress.

@grochocki grochocki changed the title Improve keyboard navigation Update support and keyboard documentation Jun 5, 2019
@grochocki grochocki added the help wanted Issues identified as good community contribution opportunities label Jun 22, 2019
@Symbai
Copy link

Symbai commented Jul 14, 2019

This a huge problem especially because there are too many different ways being used already which is for a user like me very confusing.

Example:

  • Pressing ALT reveals the "H" over the menu but it does not reveal F5 to switch to hexdecimal input in programmer mode (like shown in the mock up in the first post of this issue)
  • Mouse hovering over the "MS" in programmer mode gives a tooltip with revealing CTRL+M. Mouse hovering the HEX does not reveal its F5. Pressing ALT does not reveal CTRL+M
  • Online docs cover a bit

So we have three different ways currently to show hotkeys but all of them are incomplete and just one of it reveals the shortcut for a specific action. No matter how this gets solved but I suggest that everything else should be "fixed" to this way then. Please do not leave the current behavior untouched if possible.

@yatli
Copy link

yatli commented Dec 13, 2019

After tolerating it for long enough, with no awareness of the new keys (IIRC, in the old calc.exe it was CTRL+1 .. CTRL+4), I finally landed here.

Glad it's already implemented.

I still prefer CTRL+1...CTRL+4 though. :)

Poking around here's what I get with the fn keys:

  • Simple
    • F9 - negate
  • Scientific mode
    • F3..F5 - DEG/RAD/GRAD
    • F9 - negate
    • F-E is not mapped
  • Programmer mode
    • F2..F4 - DWORD/WORD/BYTE
    • F12 - QWORD -- why F12 though? almost missed this one.
    • F5-F8 - HEX/DEC/OCT/BIN
    • F9 - negate
    • Bit toggling is not mapped
    • ~ - NOT
    • & - AND
    • ^ - XOR
    • | - OR
    • NOR is not mapped
    • NAND is not mapped
    • < / >
    • F2..F4, Bitwise shortcuts steal focus so Enter doesn't work as = anymore, but Esc is still CE. 💔
  • Overall
    • F1, F10..F11 never mapped
    • We got ranges F3..F5, F2..F4, F5..F8 and they are not aligned, and quite arbitrary.

@davidgilbertson
Copy link

Even something basic like a link to this page in 'About' would be an improvement: https://support.microsoft.com/en-au/help/13805/windows-keyboard-shortcuts-in-apps

@grochocki
Copy link
Contributor

Even something basic like a link to this page in 'About' would be an improvement

This support page was very recently updated with a complete list of keyboard shortcuts. Adding a link to this in the about page seems reasonable in the short term. Will include in #596.

Long term, we don't think memorizing (or even referencing) a somewhat obscure list of shortcut mappings makes a lot of sense. #526 and #620 are intended to add support for more natural keyboard input (i.e., if you want cosine, you just type out "cos", and not have to remember that the shortcut key is mapped to 'o'), similar to what we are introducing in graphing mode.

@yatli
Copy link

yatli commented Sep 29, 2020

Please don't change existing shortcuts: #1396

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement help wanted Issues identified as good community contribution opportunities needs spec Pri: 2
Projects
None yet
Development

No branches or pull requests

7 participants