Interface for Markdown support of NcRichContenteditable
Opened this issue · 20 comments
Mock-up for Markdown support of richtext
The popup should be shown after finishing the selection of some text (mouse button release) and should hide as soon as selecting one option. Also [ESC] should be able to close it.
Originally posted by @szaimen in nextcloud/spreed#1027 (comment)
Comments
Copied from nextcloud/spreed#1027
-
@szaimen When selecting the formatting, markdown syntax should be used to directly add characters around the marked text and adjust the look of it.
-
@nickvergessen That would be on rightclick?
But that is something the vue library should handle anyway, so that when an app uses the input component it can say "yes markdown please" (like NcRichText afterwards for the posted messages already does for the post rendering)-
@szaimen I would say it should rather be shown directly as soon as you select some text. (e.g. after the mouse click is done and text was selected)
- @nickvergessen After a mouse select it might be okay, but I can see how keyboard users are annoyed. Like most of the time I have to fix my text selection with the keyboard because I failed with the mouse. I can see how it could be annoying then if arrow up/down are "captured" by the dropdown instead of adjusting the text selection.
-
-
-
@ShGKme It's a bit unclear to me, how "remove formatting" is supposed to work
-
@nickvergessen I guess that only would be available work, when the same style-marker (e.g. ** in the screenshot) is to the left and right of the selection. But I agree that the removing thing looks very complicated.
- @szaimen Indeed that looks complicated. So lets for now not offer this.
-
-
@nickvergessen Syntax is Markdown, so it can be rendered by NcRichText. Nothing to discuss there really.
Also when selecting text and hitting BackSpace or Delete, the text should vanish and not the special key being killed/ignored because of the Formatting option popup
So maybe only show this if selecting text with the mouse? Not sure if we can seperate between these...
I think that the menu upon selecting the text would be useful (yes only on mouse and tap), but I would prefer to have a buttons bar with just the icons in line, just like in Nextcloud text's top-bar. I think it would be much less obtrusive.
Ref screenshot from Text:
I'd personally prefer to have a user setting show text formatting. Then, a user can switch between the context menu and the bar.
Wait I don't mean the whole bar, just a few action within the context menu
@marcoambrosini you mean like a horizontal list only with icons instead of the vertical list that I suggested?
I'm not sure about icons without text. But I'd definitely remove the "Choose formatting" visual title. It seems to be obvious that it's about formating.
@marcoambrosini you mean like a horizontal list only with icons instead of the vertical list that I suggested?
Exactly, what do you think?
But I'd definitely remove the "Choose formatting" visual title. It seems to be obvious that it's about formating.
I would honestly keep it for better UX.
@marcoambrosini you mean like a horizontal list only with icons instead of the vertical list that I suggested?
Exactly, what do you think?
I tried this but for a good UX we should have some kind of labels for the buttons imho and then the vertical list also with the choose formatting looks best imho.
Here are the variants that I tried:
So in my opinion is this still the best version:
Hmm I'm actually having a look at the competitors and there's to a widely adopted pattern of being able to toggle a formatting bar. What do you think about that @szaimen? It seems like a pretty good solution to me.
I have some concerns regarding proposed tooltip mainly because it might in the way of text editing in terms of selecting, copying, cutting, pasting. For example if I select some text that I want to copy and paste above, but the formatting tooltip covers the area of the message where I want to insert the prompt to then paste, what do I do? How do I dismiss the formatting tooltip? Click outside? But then do I loose the selection? I likely wouldn't I suppose. I think that it adds a bit of uncertainty and friction and I would prefer to go with the established pattern.
Do I need formatting? -> I unfold it and it's there all the time.
I won't ever need it? -> It never gets in my way!
I think it's a very good solution UX-wise and it's also future proof, in case we want to introduce more functionality in the future.
google chat
Screen.Recording.2023-07-25.at.15.10.42.mov
slack
Screen.Recording.2023-07-25.at.15.11.36.mov
teams
Screen.Recording.2023-07-25.at.15.12.22.mov
@ShGKme if you were previously referring to this I'm sorry, I misunderstood you. I thought you meant a setting in Talk settings.
I would honestly keep it for better UX.
While usually I prefer to have a text near the icon and headers, I think in this case it is fine to keep only icons and remove any text out of tooltips.
They are very wide-known icons that are used in all text editing apps and many messengers. With a text context menu - it is a context menu, and usually they do not have additional headers when not needed.
In a horizontal menu bar, there is no space for text.
So I'd prefer to remove the header and in the menu bar - also remove the text.
(For a11y purpose, we can, of course, add hidden labels and headers.)
@ShGKme if you were previously referring to this I'm sorry, I misunderstood you. I thought you meant a setting in Talk settings.
Actually, I meant Talk settings :D
Some time ago Slack had it as a global setting option.
But having a switcher in the input is definitely better 👍
For example if I select some text that I want to copy and paste above, but the formatting tooltip covers the area of the message where I want to insert the prompt to then paste, what do I do? How do I dismiss the formatting tooltip? Click outside? But then do I loose the selection? I likely wouldn't I suppose
Yep, you can dismiss the menu by dismissing the selection (with any click or arrows). If you want to past this text in another place, then you have it in the clipboard and won't lose it after dismissing the selection.
- Select the text
- Copy
- Dismiss selection by click / arrow / Esc
- Past the copied text wherever you need
A user can also still use the native context menu, like in Notion:
So I'd keep the context formatting menu when the bar is not shown.
So I'd keep the context formatting menu when the bar is not shown
I would avoid the context formatting if we have a bar option. I might think otherwise in a text document, but in Talk the purpose of a formatting bar would be avoiding that kind friction generated by a popover blocking parts of the message I'm writing.
So I'd keep the context formatting menu when the bar is not shown
I would avoid the context formatting if we have a bar option. I might think otherwise in a text document, but in Talk the purpose of a formatting bar would be avoiding that kind friction generated by a popover blocking parts of the message I'm writing.
I would agree, that would also solve the keyboard/mixed usecase where otherwise you are always bothered by a formatting bar, while you are just trying to rewrite a section of your message or something alike.
An alternative to a formatting bar would be something like this: nextcloud/text#4587. However the question would of course would be how good this would be discoverable for first-time users.
And that requires picker support (e.g. not available in the talk desktop client atm). Something basic would be preferable I think.
Here's how it could look in Talk. What do you think? Should we open a separate issue there? I think that that the tooltip could be still totally valid for documents like the in notion example above.
Should we open a separate issue there?
So a persistent bar in Talk and a on-selection-popover in vue? Yeah should be separate tickets 👍
I've been testing the formatting bar in Signal and I have to say it works pretty well in a chat application too. Since we're going to have that built into this component, we could test that with talk before adding a dedicated bar.
If that works well we just keep it, otherwise, we create a separate issue and look into the persistent bar.
@szaimen this is much less obtrusive than the labeled version and seems to be widely adopted.
Signal example: