Thanks for the proposal - while I really appreciated this feature
several times, I never felt comfortable with the visual and design approach.
Your mockup claims that all documents can be restored - this would be
ideal, but I think it is not realistic (in some cases not to the last
modifications, sometimes not at all ?)
The wording should reflect this:
"Information about the documents open when LibreOffice crashed have been
stored. Select the documents you want to be restored using this data
from the list below:"
(Or something like that)
If we set up a crash reporter one day, it should be re-implemented in
I think about a check-box below the progress bar, checked or unchecked
depending on a entry in Tools - Options.
A text field and a button would appear at the side of the check-box, if
it is selected, where the text field should ask for the last action
before the crash and the buttons opens a editor window (input box?)
containing all the information sent to us.
At the moment I don't have the time for following this topic more
intensive (probably after LibO 3.3 release), and others will probably
have the same (time) problem.
So please misinterpret no feedback as negative - we'll probably follow
On 28/11/10 10:02, Bernhard Dippold wrote:
> Hi Andrew, *
> I didn't find a mail on this list you replied to - can you tell me where
> the "RE:" comes from?
RE: - Regarding, I put it there myself, it wasn't a reply :)
> I added the [UX] tag to the subject - allowing team members specifically
> interested in this area to find such postings more easily.
Cool, I shall do this in the future
> Thanks for the proposal - while I really appreciated this feature
> several times, I never felt comfortable with the visual and design approach.
> Your mockup claims that all documents can be restored - this would be
> ideal, but I think it is not realistic (in some cases not to the last
> modifications, sometimes not at all ?)
All my mockups claims is that if a document can be restored, it should
be in the list. If it cannot, it should not be in the list. I think this
is a fair assumption.
I don't know about the code side of things, but it would be useful to
know about whether recovery could actually fail, in which case the
design would have to change, however the behaviour in the mockup is the
> The wording should reflect this:
> "Information about the documents open when LibreOffice crashed have been
> stored. Select the documents you want to be restored using this data
> from the list below:"
I have to disagree with you on this, that is very confusing, and not
clear/succinct as the wording in the mockup. I don't think it adds
anything over what I have in the mockup.
(I don't mean offence by this, especially if English is not your native
> If we set up a crash reporter one day, it should be re-implemented in
> this screen.
> I think about a check-box below the progress bar, checked or unchecked
> depending on a entry in Tools - Options.
Sure I agree with you on this, it would be easy to add this in.
> A text field and a button would appear at the side of the check-box, if
> it is selected, where the text field should ask for the last action
> before the crash and the buttons opens a editor window (input box?)
> containing all the information sent to us.
I think maybe a separate screen would be more appropriate, depending on
the quantity of pieces of data needed.
> At the moment I don't have the time for following this topic more
> intensive (probably after LibO 3.3 release), and others will probably
> have the same (time) problem.
> So please misinterpret no feedback as negative - we'll probably follow
> up later...
Am Sonntag, den 28.11.2010, 16:44 +0000 schrieb Andrew:
> > At the moment I don't have the time for following this topic more
> > intensive (probably after LibO 3.3 release), and others will
> > probably have the same (time) problem.
Time constraints? Count me in ;-) I tried to comment on your mail, but I
miss some time to formulate my questions. At the moment, it is just a
list of disordered items :-)
But Andrew, thanks for asking for comments on that list. It seems that
you proposal is the first "real one" to be discussed here. And this
feels great (to me)!
I really like the mockup -- it is certainly an improvement over the current
However, my problem with Document recovery lies in the way it works.
Ideally, I should be able to recover my documents at any time, not just the
one time I launch LibO after it is closed.
On more than one occasion, I've force quit OOo when I saw a Document
recovery dialog pop up, because a) I needed to quickly write a few notes and
didn't have the time and motivation to deal with Document recovery, or b) as
I often work on a shared computer, the files in Document recovery are
sometimes not even mine.
I think it'd be more comfortable if the dialog provided a "Recover later"
option. It would also be great to be able to compare the recovered version
and the saved version right from the dialog.
When opening existing files that have not yet been recovered, the Recovery
dialog should automatically pop up and offer the recovered version, as well
as a comparison between the recovered version and the saved version.
Am Montag, den 29.11.2010, 08:04 +0100 schrieb Mirek M.:
> Hi Andrew,
> I really like the mockup -- it is certainly an improvement over the current
> document recovery.
Yes, it is a good start. More on that a bit later.
> However, my problem with Document recovery lies in the way it works.
> Ideally, I should be able to recover my documents at any time, not just the
> one time I launch LibO after it is closed.
This is a very good point - great if this would be rather unobstrusive.
For example, this behavior (looking at MSO 2003) might be annoying as
well, since it is very hard to simply get rid of recovered documents ;-)
At least, my MSO 2007 crashed today (caused by some kind of external
extension) and I think it didn't even ask for the recovery - it simply
reloaded the file and saved it with another name. I might be wrong, but
it seems they changed that behavior.
And by the way, the OOo guys talked about this (today): "@CD: As
discussed today, we should simplify this and make use of the new pane
framework instead of fixing the current design." 
Maybe something to share experiences / thoughts ...
> When opening existing files that have not yet been recovered, the Recovery
> dialog should automatically pop up and offer the recovered version, as well
> as a comparison between the recovered version and the saved version.
Good point as well! Besides the fact that this might drive our
developers nuts (*g*), this might also be helpful for the export (...)
Cool, thanks for the wiki page and also the explanations - it helps a
lot to see the rationale for your work! But one question, did you have a
look at the issues for the document recovery?  Maybe there are even
more good thoughts ...
Okay, since you asked for it ... just a list of comments, please decide
what is helpful for your ongoing work.
If LibO crashes and the user is (later) faced to the document recovery
dialog, we may assume that this is a "related workflow". Thus, might it
be helpful to also have a look at the message (text) stating that the
documents are being saved after the crash. Mmh, may it be an idea to use
very similar looking "Document Recovery Save" and "Document Recovery
I propose to revise the formulation a bit. For example, I'd like to
explain/avoid terms like "crash" or "recovery" - if possible. Moreover,
we should use the chance to say "we're sorry" to the user ... something
we've missed all the years :-)
And, concerning the formulation - it is good manner to avoid "negative
formulations" like "Are you sure you don't want to recover..." and use
something like "Are you sure to abort/dismiss the recovery?". Something
like that. We might even add a nice graphic to soften the mood in this
certain case. And ideas? :-)
"Select the document(s) you wish to recover below." What is the default
for that; I assume all documents, or?
The buttons within the dialog a re a bit inconsistent. I know that OOo
currently ignores the usual button order in Gnome, but the "Cancel"
button changes its position within the different dialogs. The longer I
think about it ... in this case, it might be more helpful if we replace
the "Cancel" button with "Cancel Recovery" / "Delete" to make really
sure that user understands what it is about.
I don't know whether the progressbar is helpful here - first, it is
unused (you mentioned it). But during recover, the user might not know
what document might cause further issues when recovered (crash, restart,
I see the "straight to the recovered documents", but what if some of
these documents could not be recovered (does this happen)? In such a
case, feedback is essential - and the already available dialog should be
used for that. Moreover, some people even rely on feedback if everything
went fine ... many people feel more safe (and this is what we talk
about) if they can "double-check".
Another idea that comes up - if people "stare" at this dialog, and the
documents are recovered, and this dialog is still open, then it could be
even used as a kind of "task switcher" to change to the corresponding
document. The user had plenty of time to look at his/her important
document, so it is faster to use this dialog than to use the task bar
Moreover, people sometimes use similar names for the documents being
stored in different locations. Here, it seems essential to also provide
information with regard to the storage location (either directly, or
Similar issue - you wrote "treeview should ellipsize (at the end) text
too wide". Here, it might be more helpful to ellipsize in the middle of
the string (or even avoid any ellipsis). Rationale: Many people simply
add a number at the end of a document name to create different versions.
Thus, we should avoid to omit this information.
Versions. Mirek already mentioned that it may take some time until
people restart LibO and are faced with the dialog. How about adding some
"human readable" timestamp for the "auto saving"?
Some minor issues: The warning dialog misses a dialog title, and it
seems that the margins are a bit large (given the Gnome HIG for
Okay, at a brief glance ... that's it. Of course, just comments without
that much proposals :-) So please bear with me, since I just miss the
time to provide more details.
Thus, thanks a lot for your work! I'm curious to see how this will