Apache OpenOffice (AOO) Bugzilla – Issue 104466
Recovery dialog is confusing
Last modified: 2013-08-07 15:31:14 UTC
The OO.o document recovery dialog is confusing. I just realized after having to put up with it every time I load OO.o for the past year, that I could click cancel and the dialog won come back for the old documents I don't care about that were in it. The problem is the button to kill the dialog is called "Cancel", and because the dialog pops up during the initial startup process for OO.o, I always thought that "Cancel" meant "Cancel opening OO.o" I think that using clearer language on the button would be better, something like, "Cancel Recovery" or "Cancel Recovery and Continue" I've attached a screenshot of how the dialog looks today and how it could look with the different button (I also moved the progress bar to the bottom, it doesn't make sense on the top if you haven't started recovery yet.)
Created attachment 64350 [details] Here is how the dialog looks today.
Created attachment 64351 [details] Mockup suggestion for improving recovery dialog.
*** Issue 99799 has been marked as a duplicate of this issue. ***
Created attachment 64754 [details] patch to implement this
confirmed as an issue, reported a number of times
@ cd: Please have a look. This issue has had 3.3 as target but slipped from our attention. Do you think this issue makes sense for OOo 3.4? I think renaming the 'Cancel' button will be a good improvement.
cd: I am not a UX expert but a software developer. I want to get feedback from the UX team if this minor patch is an improvement from their point of view. cd->fl: Can you please give us some feedback about this patch?
- Proposed text is too long and uses '&'. Text proposal: 'Abort Recovery'. Enlarge button to fit text in other languages. But I think we face many more issues here: - Modal 'Document Recovery' dialog blocks office, so user could not work with office after restart if dialog is open. - All documents have to be recovered. (No check boxes in front of documents) - Cancel process shows up a 'Save' dialog in some cases. I know there was a technical explanation for that behavior, but users do not care at that point (see modal dialog) and want get back to work. - Could not send a report, if user does not want to recover. Could we at least kill the 'Save' dialog and introduce the check boxes?
cd->fl: Thanks for the info. I will try to find a volunteer to work on the recovery dialog.
I am a UX expert; I'm an interaction designer with Red Hat. I do not think the label "Abort Recovery" is going to solve the problem. #1, the word "Abort" in at least the English language is not the best word to use. #2, it doesn't solve the problem I articulated in making it clear which button is the one to press to actually start OO.o. Renaming "Cancel Recovery" to "Abort Recovery" does little to address this issue. The reason I added "Cancel Recovery & Continue" to the button text was to make it clear which option would allow the user to ignore the dialog. Maybe a "Ignore" button would be nice. Does the recovered document go away when you hit the cancel button, or does it keep coming back? It seems to appear every time I use OO.o but I don't know if that is because of my usage or because it retains the canceled document. If it's due to the latter, ignore is more accurate anway.
@mairin: Please feel free to change the string to whatever is appropriate for an English native speaker. The original string was just too long, so that the button to cancel would have been more prominent than the one to start recovery. If you see the recovery dialog coming up each time you start office, you are not our target audience :-). Hopefully most users will not see this dialog at all or at least not very often. But if they face it, the current process it too complex and unexpected, because users just want to get back to work. When we started the recovery project (see [1][2]) we had the goal to recover user's work environment and to receive an error report regarding that crash. Competition had different strategies implemented. One just stored documents and showed them in a list after starting the program again. The other did a screenshot from the whole desktop and recovered the office system below the scenes, what took ages before the user was able to continue to work (and happened quite often ;-). We decided to clearly state what happened and ask the user to support OOo by contributing the crash report. Main problem (IMHO) is that the current recovery process is not optimal today. We have seen this in usability tests where users were lost, because they just expected to get their Office back. Instead of Office they get a kind of modal wizard dialog blocking OOo completely. Others did not trust the recovered documents, or just had no documents open worth recovering. Today I would not implement it the same way again. So scratching an itch in current recovery process seems a little bit like lipstick on a pig :-) That's why I listed some open issues of the current process to make others aware of the general problems we have in that area. Main problem seems to me that office does not start when clicking the OOo icon or loading a document. Recovery, in whatever way, should be shown on top of the restarted program. In that context even the 'Cancel' button would be sufficient to get back to OOo. Sending crash reports should be asked once and done automatically, if the user agreed. IMHO recovered documents should just show up in a list, so that the user could pick one, if desired. [1] http://specs.openoffice.org/appwide/errorreporter/error_report_2_0_ui_specification.sxw [2] http://specs.openoffice.org/appwide/recovery/Autorecovery.sxw [3] http://specs.openoffice.org/collaterals/guides/text-style-guide.html
@CD: As discussed today, we should simplify this and make use of the new pane framework instead of fixing the current design.
set target to 3.x since not release relevant for 3.4 release.