Bug 150428 - Document Recovery UX can be improved
Summary: Document Recovery UX can be improved
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.3.5.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Document-Recovery
  Show dependency treegraph
 
Reported: 2022-08-15 16:02 UTC by i_dont_want_to_recover
Modified: 2022-12-14 19:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description i_dont_want_to_recover 2022-08-15 16:02:48 UTC
Description:
LibreOffice document recovery (DR for short) breaks UX principles as described in https://wiki.documentfoundation.org/Design/Principles :

0) DR pops up at unexpected times (ux-consistency?): After years of using LO I couldn't really figure out when DR is triggered, but it regularly comes up when I don't remember having anything that would worth saving (typically I use LO for quick preview before switching to MS Office).

1) DR doesn't let me work (ux-interruption): The document I want to open doesn't come up until I deal with the DR window, even though I try to work with a completely different document. This is probably the most annoying component.

2) Confusing wording (ux-affordance?): The action buttons on the first DR screen are called "Start" and "Discard". Since the window appears during the startup of the application, this is confusing, because "Start" can be interpreted as continuing starting the application while "Discard" can be interpreted as discarding this annoying window, while the buttons have opposite effects.

3a) It takes two confirmations to get over DR (ux-interruption, ux-visual-hierarchy): I know this should be a safety tradeoff, but it's *really* annoying to click through not one but to modal dialogs to get to my document unrelated to DR. It's also not visually easy to tell which button will result in discarding the document/continuing execution (that can either be desired or dangerous, so simple red/green coloring wouldn't do I guess).

3b) It takes a confirmation to see recovery result (ux-interruption, ux-minimalism): Let's say I really did want to recover something. What is the purpose of making me click Finish in order to my nervously awaited recovery result can be displayed?

Steps to Reproduce:
1. Save a document
2. Add some content to the document without saving
3. Kill LO
4. Open LO providing a different file (document2) in the command line to trigger DR

Actual Results:
DR shows up, preventing work on document2.

Expected Results:
I want to be able to work with document2 without blocking modals. 


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.5.2 / LibreOffice Community
Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 1 Rafael Lima 2022-08-15 21:56:29 UTC
So basically what you want is that LibreOffice only shows the DR dialog when you try to open the a file that had previously crashed? If you try to open some other file (even if a previous LO session crashed), you want the DR dialog to not be shown?

AFAIK the recovery info is obtained from the hidden backup file that is created while the document is open. So I guess this might be possible, but I'm not an expert on the inner-workings of file recovery.

Maybe we could have the following workflows:

1) If LO crashes and the user tries to open a file that has backup information, then only the DR dialog is shown (as is today)

2) If LO crashes and the user tries to open some other file, the file is opened and becomes ready for editing; and at the same time the DR dialog is shown to indicate that there are files pending recovery.

Let's hear from the UX team.
Comment 2 Heiko Tietze 2022-08-16 07:46:22 UTC
(In reply to i_dont_want_to_recover from comment #0)
> 0) ... (typically I use LO for quick preview before switching to MS Office).

Uh :-)

(In reply to Rafael Lima from comment #1)
> So basically what you want is that LibreOffice only shows the DR dialog when
> you try to open the a file that had previously crashed?

=> NEEDINFO

The dialog has been revamped recently for bug 114508 and should be more accessible now. Given the DR pops-up when needed, I guess the other inconveniences (interruption of workflow, confirmation steps) are acceptable.
Comment 3 i_dont_want_to_recover 2022-08-16 09:01:34 UTC
> So basically what you want is that LibreOffice only shows the DR dialog when
> you try to open the a file that had previously crashed?

My preferred solution would be an implementation that doesn't block startup/display of the requested document. I guess that getting notified ASAP about potentially corrupt documents is a good thing, because the user can take actions early, before the error becomes unrecoverable or cascades for some reason. It seems reasonable to block editing if a file with recovery info is opened until DR is decided, but being able to read the last saved version should be possible without the decision. 

Also, I brought up 0) because part of the problem seems to be that in my experience sometimes LO thinks it crashed when in fact it didn't. As I said, I usually only touch documents in MS Office, yet I'm still regularly faced with DR, although there shouldn't have been any modifications and I exit LO clean. (This would deserve a separate bug, but as it's non-deterministic, I can't give much details unfortunately :( ). This means that in some cases I want to work on the same document without being interrupted by DR, because I know there is no need for recovery.
Comment 4 QA Administrators 2022-08-17 03:35:33 UTC Comment hidden (obsolete)
Comment 5 Heiko Tietze 2022-08-26 07:47:07 UTC
The topic was on the agenda of the design meeting but didn't receive further opinions. 

Point is that we should aim for no crashes at all. To my knowledge, the dialog comes up if some lock file is present. And respectively you create this file with the first editing of a document. I mean, while in IT all is possible, the balance to effort is not given here.

Furthermore, I cannot confirm that the DR dialog shows up with unexpected timing - besides you start LibreOffice ages after it crashed. But leaving the ticket open for QA to verify. My take is to resolve the request as WF.
Comment 6 i_dont_want_to_recover 2022-08-30 08:46:26 UTC
> Point is that we should aim for no crashes at all.

Well, good luck with that :) 

> Furthermore, I cannot confirm that the DR dialog shows up with unexpected timing

Unexpected timing is just a circumstance in my specific case, the ticket is not about detecting recovery situations, but responding in a user-friendly way when recovery seems necessary (false detection or not).

> I mean, while in IT all is possible, the balance to effort is not given here.

Again, this ticket is not about unexpected recovery situations. IMO the current UX wastes the collective time of users, that is worth improving. I also referenced how the current behavior goes against the project's own UX principles, which was not argued. On the other side, I don't see how the effort is estimated here, as I don't see any concrete proposal for resolution.
Comment 7 Heiko Tietze 2022-08-30 09:13:05 UTC
(In reply to i_dont_want_to_recover from comment #6)
> On the other side, I don't see how the
> effort is estimated here, as I don't see any concrete proposal for
> resolution.

You suggested yourself to start the application and show an infobar telling the user "LibreOffice has crashed lately. You may recover the latest state. [Recover]" and the dialog starts on click.

What I suspect is that recovery information are overwritten if, for example, the application crashes because of a template that is loaded on start-up. It's a risky situation and the value of data integrity is higher than being interrupted. But this decision is up to the developers.
Comment 8 i_dont_want_to_recover 2022-08-30 14:39:16 UTC
> You suggested yourself to start the application and show an infobar telling the user "LibreOffice has crashed lately. You may recover the latest state. [Recover]" and the dialog starts on click.

I don't remember being this specific, but I'd like this approach :)

> It's a risky situation and the value of data integrity is higher than being interrupted.

So far the risk of recovery data corruption wasn't stated as a fact (you wrote you "suspect" there is a risk). If there is such risk, I agree that the UX should not take priority (but maybe the recovery process should be improved?).