feat: keyboard shortcuts spec #39
Conversation
|
|
||
| #### Message focus | ||
|
|
||
| - `TAB` - MUST trigger focus of the last message |
There was a problem hiding this comment.
we're currently missing the design for a 'focused message' (or at least I can't find it)
There was a problem hiding this comment.
found a design here https://www.figma.com/file/Mr3rqxxgKJ2zMQ06UAKiWL/%F0%9F%92%AC-Chat%E2%8E%9CDesktop?node-id=5395%3A46518
@John-44 can you confirm please if this is still the intended design for focusing on a message with keyboard shortcuts?
There was a problem hiding this comment.
@iurimatias no that figma link is not the intended design, that figma is out of date. Kuba is working updating the focus state designs as his next task, hopefully these designs will be ready some time next week.
There was a problem hiding this comment.
Focus state designs are here https://www.figma.com/file/IPpvkpDWabBKJTeo6bFop0/Kuba%E2%8E%9CDesktop?node-id=1759%3A332242 but I do think spatial focus based interaction should be a separate spec.
| - `OPT + ENTER + DOWN` - MUST select the next community, if there is no next community then it MUST select the first community | ||
| - `OPT + UP` - MUST select the previous channel, if there is no previous channel then it MUST select the last channel | ||
| - `OPT + DOWN` - MUST select the next channel, if there is no next channel then it MUST select the first channel | ||
| - `CMD + [` - MUST Navigate backward in page history |
There was a problem hiding this comment.
what is the difference between this and the PAGE UP short cut below?
There was a problem hiding this comment.
What is a page history in this context? What's the context anyways? Are we in chat/message view again? If yes, please specify
There was a problem hiding this comment.
Q: what is the difference between this and the PAGE UP short cut below?
A: I think the difference is "OPT + UP" and "OPT + DOWN" cycle between channels, while "PAGE UP" and "PAGE DOWN" scroll the main chat view
There was a problem hiding this comment.
@PascalPrecht all of these shortcuts are basically copied from Discord (because we want any user who is coming from Discord to be able to use all the Discord shortcuts they have already learnt), so the best way to answer questions about what these shortcuts are supposed to do is to try them in Discord ;-)
| - `CMD + E` - MUST toggle emoji picker | ||
| - `CMD + G` - MUST toggle GIF picker | ||
| - `CMD + S` - MUST toggle sticker picker | ||
| - `PAGE UP` - MUST Scroll chat up |
There was a problem hiding this comment.
what is the difference between this and the CMD + [ short cut above?
| - requirement: the message must have been sent by the current user | ||
| - `P` pins the currently focused message | ||
| - requirement: the current user must be an admin in a community or a group chat | ||
| - `+` react to currently focused message |
There was a problem hiding this comment.
this shortcut is currently unclear, because we react to messages by selecting one of the 4 possible emojis. So either the shortcut needs to be expanded like + + 1 selects the first reaction emoji for example, OR the application needs to be updated so it can support any emoji as a reaction, and this would trigger instead the emoji picker.
| - `PAGE UP` - MUST Scroll chat up | ||
| - `PAGE DOWN` - MUST Scroll chat down | ||
| - `SHIFT + PAGE UP` - MUST jump to oldest unread message | ||
| - `CMD + SHIFT + H` - MUST trigger Help |
There was a problem hiding this comment.
what would this do, i.e what is help here. would it open a particular webpage for example or a certain section in the application?
There was a problem hiding this comment.
This is a great start, however I think we need to be more explicit for some of the features mentioned in here.
Generally it seems some shortcuts apply globally, some only in specific sections, others potentially conflict within a section.
Maybe we can generally group all shortcuts by section (cause this doesn't seem to be the case right now)
|
|
||
| ## Motivation | ||
|
|
||
| Users often use keyboard shortcuts to more effectively navigate applications. This spec aims to document the keyboard shortcuts available as well as any preconditions. |
There was a problem hiding this comment.
So generally speaking, this spec is not just about shortcuts but actually being able to navigate the application via the keyboard?
If that is the case then we should make this explicit in the document as well as the title of the spec.
There was a problem hiding this comment.
@PascalPrecht I think 'command' style shortcuts (e.g. CTRL+[a key] style shortcuts) and focus based interaction (e.g. bringing up a focus ring, moving the focus ring around with cursor keys, using ENTER to activate and ESC to go a level up or exit) should be treated as two separate features and should have separate specs.
The reason I'm thinking this is because 'command' style shortcuts are relatively straightforward to implement, but implementing spatial focus based interaction is much more complex. Last time I worked on this (implementing spatial focus based interaction using QML) there were quite a few dev challenges to be overcome because QML doesn't have an inbuilt global spatial understanding e.g. if two different QML regions are next to each other, and a user presses a sideways cursor key, we would want the focus ring to jump to the item that's physically closest in the direction of the cursor key, and if this means jumping to a different region it's difficult to know the relative location of items in the other regions.
|
|
||
| ## Designs | ||
|
|
||
| * [designs](https://www.figma.com/file/IPpvkpDWabBKJTeo6bFop0/Kuba%E2%8E%9CDesktop?node-id=355%3A82493) |
There was a problem hiding this comment.
I guess a link to the designs can be added to some "resources" section.
We should better put screenshots if individual designs/userflows into the document. This makes it easier for us to actually read the spec when hosted.
There was a problem hiding this comment.
Or at least we should deep link to one of the relevant design mocks within the figma file. For example this link https://www.figma.com/file/IPpvkpDWabBKJTeo6bFop0/Kuba%E2%8E%9CDesktop?node-id=2457%3A357870 will take the viewer directly to the keyboards shortcut mock within this large figma that contains many pages.
| ### Keyboard shortcuts help | ||
|
|
||
| - `CMD + /` MUST open a modal listing available key shortcuts | ||
| - The Modal listing available keyshortcuts MUST display the correct keys depending on the platform, for example `CMD + C` on macOS and `Ctrl + C` on Windows. |
There was a problem hiding this comment.
Might want to specify that this an application-wide, global key command that applies everywhere in the app (if that is indeed the case. If not, specify as well)
There was a problem hiding this comment.
Good point! Yes this should be global app-wide, the user should be able to invoke the keyboards shortcuts overlay irrespective of where they are in the app, and even if a modal dialogue is open. This keyboards shortcuts overlay should always appear on top of whatever else is on the screen.
| - `TAB` - MUST trigger focus of the last message | ||
| - `UP` - MUST focus on the previous message | ||
| - requirement: there is already a message in focus | ||
| - `DOWN` - MUST focus on the previous message |
There was a problem hiding this comment.
This should probably say "next" nessage
There was a problem hiding this comment.
This is only if a message is focused. If (for example) an item in the L1 or L2 nav is focused then the interaction is different. And the really hard bit to implementing correctly is what happens if the user presses the RIGHT or LEFT cursor arrows to jump from say the L1 to the L2 or from the L2 to the message body area. This is difficult because it means we need to understand relative vertical positioning between these elements. Which is why I'm suggesting we descope focus based navigation for now, and come back to this task after we've got the Community MVP launched.
Or perhaps we do (for example) vertical message selection via keyboard only for now, and leave the full spatial focus based interaction work later??? But with this I worry about the user experience feeling incomplete.
We can always remove shortcuts that require spatial focus based interaction from the first version of this keyboard shortcuts overlay (so that the keyboard shortcuts overlay only contains 'command' style shortcuts), and then add the shortcuts the require the concept of focus back in later when we properly implement spatial focus based post Communities MVP?
| - requirement: there is already a message in focus | ||
| - `ESCAPE`: | ||
| - if a message is already in focus, it MUST be removed from focus and the input box MUST be focused instead | ||
| - if input box is already in focus then focus MUST BE removed completly |
There was a problem hiding this comment.
| - if input box is already in focus then focus MUST BE removed completly | |
| - if input box is already in focus then focus MUST BE removed completely |
| - `OPT + ENTER + UP` - MUST select the previous community, if there is no previous community then it MUST select the last community | ||
| - `OPT + ENTER + DOWN` - MUST select the next community, if there is no next community then it MUST select the first community | ||
| - `OPT + UP` - MUST select the previous channel, if there is no previous channel then it MUST select the last channel | ||
| - `OPT + DOWN` - MUST select the next channel, if there is no next channel then it MUST select the first channel |
There was a problem hiding this comment.
These suggest that chat or community view has to be active. We should specify this in the spec as well.
As mentioned in the previous comment do these shortcuts apply to other sections as well? Or can they? E.g. OPT+UP/DOWN could work inside the settings sections to navigate through settings subsections.
If that is intended we need to specify the scope in which the key commands have which effect
| - `OPT + ENTER + DOWN` - MUST select the next community, if there is no next community then it MUST select the first community | ||
| - `OPT + UP` - MUST select the previous channel, if there is no previous channel then it MUST select the last channel | ||
| - `OPT + DOWN` - MUST select the next channel, if there is no next channel then it MUST select the first channel | ||
| - `CMD + [` - MUST Navigate backward in page history |
There was a problem hiding this comment.
What is a page history in this context? What's the context anyways? Are we in chat/message view again? If yes, please specify
| - `OPT + SHIFT + UP` - MUST select the previous unread channel, if there is no previous unread channel then it MUST select the last unread channel, if there is no unread channels then it MUST select the first channel | ||
| - `OPT + SHIFT + DOWN` - MUST select the next unread channel, if there is no next unread channel then it MUST select the first unread channel, if there is no unread channel then it MUST select the first channel | ||
| - `OPT + SHIFT + OPT + UP` - MUST select the previous unread channel with mentions, if there is no previous unread channel with mentions then it MUST select the last unread channel with mentions, if there is no unread channels with mentions then it MUST select the first channel | ||
| - `OPT + SHIFT + OPT + DOWN` - MUST select the next unread channel with mentions, if there is no next unread channel with mentions then it MUST select the first unread channel with mentions, if there is no unread channels with mentions then it MUST select the first channel |
There was a problem hiding this comment.
These again only apply in chat/community view. Let's make this explicit in the spec
| - `SHIFT + ESCAPE` - MUST mark as community as read | ||
| - `ESCAPE` - MUST mark a community channel as read | ||
| - `CMD + P` - MUST toogle pins popout | ||
| - `CMD + i` - MUST toogle inbox popout |
There was a problem hiding this comment.
Activity centre. I've just updated the text in the figma
| requirement: a community must be selected | ||
|
|
||
| - `SHIFT + ESCAPE` - MUST mark as community as read | ||
| - `ESCAPE` - MUST mark a community channel as read |
There was a problem hiding this comment.
This conflicts with one of the key commands specified above where hitting ESC without a message being focussed causes the chat input to gain focus.
There was a problem hiding this comment.
Can we have 2 more shortcuts:
From anywhere:
CMD + K to navigate to any channel
From the chat when the input is selected,
doing Up, will go edit your previous message
Did we look at discord/slack for there shortcuts? I'd suggest to clearly inspire our self from them as they are already natural shortcuts for a lot of people
|
@PascalPrecht @iurimatias all of these shortcuts are basically copied from Discord. We want any user who is coming from Discord to Status to be able to use all the Discord shortcuts they have already learned. So the best way to answer questions about what these shortcuts are supposed to do is to try them in Discord ;-) We can perhaps add additional additional shortcuts that aren't in Discord, our first priority is to emulate discord's shortcut behaviour |
@alaibe these shortcuts are basically a direct cut and paste of Discord's shortcuts ;-) And they should behave in exactly the same way in Status Desktop as they do in Discord (to the maximum extent possible) |
|
|
||
| ### Keyboard shortcuts | ||
|
|
||
| #### Message focus |
There was a problem hiding this comment.
I wonder if this whole section should be moved into a separate 'spatial focus based interaction' spec?
Then implementing just the keyboard commands becomes a much smaller and simpler task.
closes #10 and #12