Make collabora save and exit actions more intuitive

[oanalavinia]

Right now, these are 2 actions are separated, which can be very confusing and not consistent with other editors.
On one hand, the save action is integrated in the Collabora editor, as part of it's UI, and on the other the cancel button is outside the editor, on the right up corner, giving the impression that it would cancel the current edit without any save.

An improvement would be to have a close button integrated in the editor. This would act as a save and close, giving the option to save unsaved work.
This way, the current cancel action will be transformed into a close that notifies the use that unsaved work will be lost.

[oanalavinia]

Investigation: Collabora provides api for Action_Close https://sdk.collaboraonline.com/docs/postmessage_api.html#id1 .

[lucaa]

Also, I tested and it appears that hitting cancel actually saves the page if a save was not performed. This is very strange, as far as I understood it shouldn't happen, and it's definitely counter-intuitive in terms of UI.

[oanalavinia]

The save was not done by the cancel button, but by the automatic save feature of collabora, which is on by default (see for example https://forum.collaboraonline.com/t/disabling-auto-save-in-collabora-online-code/597). You can test it by leaving the editor with unsaved changes for some time. Unfortunately, there is no UI to make it visible.

[oanalavinia]

I first draft for moving the actions inside the menu was added here #16.
However, after a discussion with @lucaa , there are some questions that should be answered before deciding on a specific UI.
It's important to consider that there are (and potential will be) other editors integrated in XWiki. Each has their own APIs and UI, but it's important to keep, as much as possible, a consistency between them, to make it easy for users to find, for example, the save or close buttons.
Until now, we have https://github.com/xwikisas/application-onlyoffice-connector, were the action buttons are in the top right corner, having a similar UI with the page action buttons.

Should this be the case for all integrated editors? Or should we try to integrate the buttons inside the editor, like it was done on the above PR? The last option might not be possible for all editors, or will not give the same possibilities in terms of UI, which will make the buttons harder to be discovered (see #16 (comment) where some problems for Collabora are presented).

It's important to consider that users that are familiar with XWiki might look for the buttons similar to the page actions, while those that know a specific editor will look inside the editor.
Also, moving some actions outside the editor might lead to some features being lost, depending on each editor APIs. For example, in Collabora if there are unsaved changes, this is signaled near the save button.

[mflorea]

It's important to consider that there are (and potential will be) other editors integrated in XWiki.

Yes, but we need to distinguish between:

• editors that are integrated "in-place", within the XWiki UI, such as the draw.io diagram editor and
• editors that are always shown full screen, such as the OnlyOffice and Collabora editors, where we only show an XWiki banner to indicate that the edited content comes from XWiki.

I think that for the second type of integration (full screen) we should rely as much as possible on the editor buttons and when needed use the provided hooks (extension points) to extend the editor UI with our custom buttons / features (e.g. add toolbar buttons or menu entries). What we did for OnlyOffice doesn't look very good. Sure, our custom buttons are very visible but they are not integrated in the editor UI / look & feel.

[LMonert]

Not sure if still relevant but just in case some input: I am currently testing the onlyoffice and collabora integrations for a client that considers purchasing one of them and from what I am seeing I totally agree with @mflorea here. The bar on top in the current onlyoffice integration does not create the best user experience because of the design differences and the reduced screen size. I noticed this especially when working on my laptop - the top bar really takes room away and makes the UI look cramped. I also would argue that the experiences user have with the traditional save and close buttons from their other office applications tends to overshadow XWiki habits in this case and that they as a result expect the buttons to be there and work / look the same way.

[snazare]

To make a decision on generic ui vs integration specific. Get feedback from designer.

[snazare]

Our designer will be back with a proposal in the second week of July.