Hey everyone, this is a proposal for the switching between source and visual edit modes in Cristal. Overall, this is pretty straightforward, but I have two options for it, based on the presence of a main edit toolbar.
Visual and Source Mode: Proposal for Mode Switching
The Visual mode (called WYSIWYG in XS) is an editor mode where all font choices, colors, and styles appear exactly as the user intends. This is the more intuitive and also the default mode.
Source mode, on the other hand, replaces the visual representation of the document with its actual source code as interpreted by the application. This mode primarily serves as a debugging tool, catering to advanced users who need direct control over the document’s structure.
Quick Mode Switching: Transitioning between WYSIWYG and Source mode should be seamless, ideally supported by a simple keystroke for advanced users.
Clear Visual Indication in Source Mode: When Source mode is active, the content area should visually reflect this change to ensure users are fully aware of their editing environment. My proposal here is to make it lightly gray not too distracting but clear enough to convey a different mode of operation.
Without the main toolbar, the button can have a less prominent placement.
Since mode switching is a secondary feature, the button could be positioned at the bottom of the screen, always visible but outside the main content flow.
Thanks Thiago. We discussed also addressing XS at the same time when proposing new Cristal UI/UX improvements. I would be interested to discuss how this would apply to XS and make sure we agree about it at the same time. WDYT?
Re the 2 options, I’m not sure I understand. Does it mean that Cristal supports 2 edit modes (with a main toolbar visible and without)? Or, is this a proposal to change the edit UI (by removing the toolbar)?
You are right, I forgot abou it when doing the proposal and I’ll update it asap, shouldn’t take too long.
Only one of the options should be available. I posted two because I am not sure at this stage if we’ll provide a default, always visible, toolbar or not.
Currently, we have everything on the toolbar menu, visible when selecting some content and on the slash (/) menu. So option 2 would be used.
Edit: Testing Notion and Cristal a little bit and I could not use the floating toolbar only with my keyboard, so I believe this is a huge accessibility problem. @CharpentierLucas Do you know something about best practices with these type of components? The user is editing text in this context, so a simple arrow up or tab is not enough.
From what I know of CKEditor, you have keyboard commands to do anything, so technically you CAN do anything with keyboard only, even if most people don’t know it all.
For CKEditor, in addition to that, they have a hint for screen readers somewhere at the start of the editor to “Press ALT 0 for help”. Alt 0 opens their accessibility instruction dialog, which contains plenty of info to use the editor with only a keyboard
General
Editor Toolbar
Press Alt+F10 to navigate to the toolbar. Move to the next and previous toolbar group with TAB and SHIFT+TAB. Move to the next and previous toolbar button with RIGHT ARROW or LEFT ARROW. Press SPACE or ENTER to activate the toolbar button. The focus will be moved back to the editing area upon activating the toolbar button.
Editor Dialog
Inside a dialog, press TAB to navigate to the next dialog element, press SHIFT+TAB to move to the previous dialog element, press ENTER to submit the dialog, press ESC to cancel the dialog. When a dialog has multiple tabs, the tab list can be reached either with ALT+F10 or with TAB as part of the dialog tabbing order. With tab list focused, move to the next and previous tab with RIGHT and LEFT ARROW, respectively. Press ESC to discard changes and close the dialog. The focus will be moved back to the editing area upon leaving the dialog.
Editor Context Menu
Press Shift+F10 / Shift+Ctrl+F10 or APPLICATION KEY to open context-menu. Then move to next menu option with TAB or DOWN ARROW. Move to previous option with SHIFT+TAB or UP ARROW. Press SPACE or ENTER to select the menu option. Open sub-menu of current option with SPACE or ENTER or RIGHT ARROW. Go back to parent menu item with ESC or LEFT ARROW. Close context menu with ESC.
Editor List Box
Inside a list-box, move to next list item with TAB OR DOWN ARROW. Move to previous list item with SHIFT+TAB or UP ARROW. Press SPACE or ENTER to select the list option. Press ESC to close the list-box.
Editor Element Path Bar
Press Alt+F11 to navigate to the elements path bar. Move to next element button with TAB or RIGHT ARROW. Move to previous button with SHIFT+TAB or LEFT ARROW. Press SPACE or ENTER to select the element in editor.
Commands
Undo command
Press Ctrl+Z
Redo command
Press Ctrl+Y / Shift+Ctrl+Z
Bold command
Press Ctrl+B
Italic command
Press Ctrl+I
Underline command
Press Ctrl+U
Link command
Press Ctrl+K / Ctrl+L
Access previous focus space command
Press Shift+Ctrl+3 to access the closest unreachable focus space before the caret, for example: two adjacent HR elements. Repeat the key combination to reach distant focus spaces.
Access next focus space command
Press Shift+Ctrl+4 to access the closest unreachable focus space after the caret, for example: two adjacent HR elements. Repeat the key combination to reach distant focus spaces.
Accessibility Help
Press Alt+0
Paste as plain text
Press Shift+Ctrl+V
Having the shortcuts is not enough, you need to let your users know about it for anything that’s non standard
With CKEditor, they use ALT+F10. I don’t think it’s a standard though.
