We found out two issues with the newly integrated comments rich editor.
This has a negative impact on page load time
This can break the use of keyboard shortcuts (cf XWIKI-17614)
For these reasons, we propose to not activate the rich editor by default and to only activate it on demand.
You will find below two design proposals for this evolution.
Proposal 1
Adding a clickable text to expand the comment input field on click.
The comment form would only be expanded when the text is clicked.
I’m +1 for proposal 1 but I don’t really like the proposed design.
Since we used to have the whole width to click on for starting to type the comment, I think I would have preferred to have some kind of fake full-width div button that you could click on directly.
Thinking about something like that:
Well proposal 2 is about providing in the html an actual textarea, while I’m proposing to have an actual div element. The difference is important since I don’t know how this textarea would need to be handled with some JS to be transformed when you focused on it, which might be unexpected for users. While with my solution you expect some reaction when clicking on the button.
From a technical and implementation POV it might be different (but not so much since transforming a DIV or a TEXTAREA is the same IMO; they both require JS to replace the element) but from a user POV it’s about having a zone (like a textarea) that you click and that transforms into a WYSIWYG editor.
Well it all depends how you plan to show proposal 2, but if the proposal is to keep displaying the old textarea we used to have then I don’t agree with your assumption. Because in that case, the user POV is to be able to type directly his text when he clicks on the textarea, not the textarea to be transformed in any way.
Isn’t that what you’re proposing? Your suggestion really looks like a one-row textarea. It has a text of “click to add a comment…” which I assume (and I think it’ll a general assumption from users seen that it doesn’t look like a button and it’s not the style or the xwiki buttons) that if you click it, then you can then start typing a comment. That’s exactly how the textarea proposal would work too.
Difference is that in my proposal it’s not a textarea, but really a button so you definitely cannot type once you clicked on it. You have to wait. While with proposal 2 since it’s a textarea, you’ll be able natively to type once you clicked on it, so you might lose what you type if it takes a bit of time to load or to interact with the focus event etc. That’s the main issue I see and that’s why I’m actually -1 for Proposal 2.
Now I’m open to discuss about the design of the button for Proposal 1, I don’t like the first design proposal made but maybe it’s only me.
Indeed that’s true that there’ll be a lag (to load the WYSIWYG editor). But you cannot type in the textarea since it doesn’t have the focus so you first need to click on it, that’s why I don’t see the difference. If there’s a way to capture the tab keypress so that we also transform it into a wysiwyg editor when you tab to it, then it’ll be the same as a button no?
What I don’t like too much with your proposal is that it’s not standard and not consistent with the controls that xwiki uses.
Well you’re bringing me more arguments there There’s no textarea until you clicked in Jira. It’s a div which is transformed. So yeah I’m +1 to go towards something like that since it’s not a textarea (i.e. I cannot type until it’s loaded or if there’s an issue with my JS).
So to recap, for me the 2 proposals so far can be seen on Loading...
In the description area (clickable area - proposal 2)
In the comments area (button - proposal 1)
ok cool, we’re talking about the same thing. I said textarea but I’ve used the wrong terminology. I meant a zone that can be clicked and when you click on it it transforms into a WYSIWYG. The closest mental image I had was a textarea (a DIV is not visual).
Side note: We still need to handle the TAB keypress for accessibility if we choose proposal 2.
To summarize, solution 1 involves a button (with the style proposed by @mflorea, and the “Add comment” label proposed by @tmortagne). Clicking on the button displays the comment form.
Solution 2 offers a zone that has the look of an editable element (eg, textarea) and becomes active once the user click on it.
In any case it’s closer to proposal 2 than proposal 1.