Description: - Create Writer document and export file to PDF. - Do some changes and export again with the same name. - In dialog now "Yes/No" buttons are displayed. - If "Yes" is clicked old document on disk is REPLACED with new version. This is bad UX issue. - Suggestion rename buttons to "Replace/Cancel" combination. Steps to Reproduce: 1. Open Writer and in new document type some text e.g. test1 2. File | Export As | Export as PDF 3. On opened dialog click on Export button to export document. 4. On opened dialog leave default file name and click on Save button to save PDF document. 5. Now change some text e.g. test2 6. Repeat steps 2 to 4. Actual Results: 7. Now dialog appears with "Confirm Save As" in title bar and "Untitled 2.pdf" already exists. Do you want to replace it?" There are two buttons "Yes" and "No". 8. I just read "Confirm Save As" and clicked "Yes", I assumed there will be new "save as" dialog opened, but instead file was replaced and I lost older version of document. Expected Results: a) Title bar should be named "Confirm Replace". b) "Yes" button should be renamed to "Replace". c) "No" button should be renamed to "Cancel". In my humble opinion when something so dangerous as losing older version of document is in making, Yes/No question should never be used. This is bad UX. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: sl-SI (en_SI); UI: en-US Calc: CL threaded
Created attachment 197169 [details] Yes_No_buttons.png
Note that the dialog shown on Windows is an operating-system-provided dialog. It's not what LibreOffice shows. Microsoft considers that confirmation a good UI/UX; trying to interfere into the default OS behavior, changing that dialog, would be actually a worse UX for all the users who are accustomed already to the OS-standard behavior. On Linux (specifically, GTK), the dialog is custom; the code pointer is STR_SVT_ALREADYEXISTOVERWRITE_SECONDARY constant (https://opengrok.libreoffice.org/search?&full=STR_SVT_ALREADYEXISTOVERWRITE_SECONDARY&project=core&sort=fullpath). No idea how GTK UX guidelines align with existing / proposed button names.
@Mike, bellow are recommendation for Microsoft and GNOME projects. 1. Windows https://learn.microsoft.com/en-us/windows/apps/design/controls/dialogs-and-flyouts/dialogs 2. GNOME https://developer.gnome.org/hig/patterns/feedback/dialogs.html
Created attachment 197178 [details] Action and cancel buttons.png
In fpicker/source/office/RemoteFilesDialog.cxx the call is <weld::MessageDialog> xBox(..., VclButtonsType::YesNo...); Using special labels on the buttons makes the dialog non-standard. Some effort for little benefit.
(In reply to grofaty from comment #3) > @Mike, bellow are recommendation for Microsoft ... > > 1. Windows > https://learn.microsoft.com/en-us/windows/apps/design/controls/dialogs-and- > flyouts/dialogs It doesn't matter. As I wrote, we don't create *that* dialog on Windows. If MS is not consistent in what it suggests over what it provides; or if its recommendations depend on the framework used for the specific app's UI - the result is the same. In MS native Win32 file dialogs, that is the OS-supplied dialog used for the confirmation. We won't change that on Windows, until we change the whole framework.
Caolan, what's your take on variable strings for the MessageDialog? Some overloaded function to not pick up VclButtonsType but use a string vector.